r (r@freesoftwareextremist.com)'s status on Monday, 18-Sep-2023 16:18:42 JST
rPatch for the vulnerability in bloat that allows a malicious upstream server (Pleroma/Mastadon) to return crafted JSON data in the response of an API called by bloat to make it go out of memory and cause Denial of Service. The attack could be performed by a malicious user by connecting to a malicious server. Technically, it doesn't have to be a Mastodon compatible server, any HTTP server that'd respond to the HTTP paths requested by bloat could work. bloat instances running in the single instance mode are not affected assuming the specified instance doesn't serve the malicious response. The patch applies a limit on the size of the response returned by the server, currently set to 8MiB. https://git.freesoftwareextremist.com/bloat/commit/?id=ad38855261dca802439922f71408e2b08e7c10ea
@r@Moon@dcc@kirby@p@w >bloat instances running in the single instance mode are not affected I think they might be. If you authorize to an instance A, then change bloat's config to be in single instance mode for instance B and restart it, auth cookie for instance A on said bloat server will keep working. Crafting your own cookie pointing to malicious server with arbitrary oauth tokens should be possible as well.
@mint@dcc@w@r@p@Moon i swear if he presents this as the critical security issue that caused some panic words will not be able to describe how upset I will be
@mint@dcc@w@r@p@kirby@Moon yeah it’s a fucking nothingburger. some software can leak memory even on legitimate workloads so if you have no system-wide way of guarding against that, just don’t host anything
@r@Moon@dcc@kirby@p@w Had to resolve a bunch of merge conflicts since upstream made some changes to templates as well. Apparently, go's template engine takes precedence to .orig files made by git merge which confused me for a while before I cleaned them up as usual. Should be up on https://gitgud.io/mintplg/bloat, agency's/salon's bloat will follow shortly. Screenshot_20230918_141335.png
Just to clarify. What I meant is that it is very close to intended behavior of the http package. Probably the original "security researcher" found someone concern trolling on git about it and thought he'd milk it here.
@r@Moon@dcc@kirby@mint@w Not super critical, but go.mod says 1.13, and it doesn't build with 1.17. http.MaxBytesError was added in 1.19 so I tweaked go.mod to do it that way. tweak.patch
@p@dcc@w@kirby@mint@Moon And the README mentions 1.11 as minimum required version. I remember changing a few things to keep it compatible with 1.11, but that was quite a while ago. The reason for sticking to that version was because then current Debian stable had it. Will see if it's worth sticking to that by refactoring the code a bit or just change it to a newer version.