Server Error Reports

[gnif]

Oh it certainly is, but it's not something that can be fixed easily.

SMF is dumb and just allows you to upload any file, and when it's an image attempts to create a thumbnail at render time (not at upload time), not only does this mean that multiple concurrent page loads will try to generate the thumbnail at once, if there are multiple images on the page, it will do them all at once (which can be slow) and cause a timeout, preventing the database from being updated with the information about the thumbnails.

The core workflow is very broken and fixing it will require overhauling how things work here. Such a "fix" would make SMF incompatible for future updates/upgrades.

[magic]

At least the previewer should be fixed not to choke on malformed PNGs.
Is it exploitable for RCE too?

[gnif]

I did add some idiot checks for this some time back but upgrades to SMF and/or modules have undone it. I will schedule some time to investigate and re-instate what I can.

I am not sure if it's a RCE issue, IIRC it's the thumbnail preview feature which I think is an "addon" (if you can call SMF addons 'addons', more like diffs/patches)

[magic]

Hmm, I found this, which suggests that thumbnails are core SMF functionality. I have no idea, never administrated SMF myself.
https://wiki.simplemachines.org/smf/SMF2.0:Attachments_and_Avatars

RCE could possibly be an option if it's some old lousy C program which generates those thumbnails. If they actually wrote their own PHP scripts to parse those PNGs then maybe not. Again, no idea how they actually do it.

[magic]

Isn't this the culprit?
https://github.com/SimpleMachines/SMF2.1/blob/release-2.1/Sources/Subs-Graphics.php#L395

It seems to use one of three libraries, depending on availability. I suppose you could see if installing a different backend solves it, or file a bug with the backend's vendor. I'm not sure if I would want to run remotely executable C binary which can't even recognize that it's being fed a BMP instead of PNG and tries to process it instead of bailing out.

Or maybe the backend does bail out and SMF goes nuts? Then it would be an SMF bug.

[gnif]

It needs to be fixed in SMF, it just hands everything to `imagecreatefrom` based on the extension.

```

Code: [Select]

        // A known and supported format?
        if (isset($default_formats[$sizes[2]]) && function_exists('imagecreatefrom' . $default_formats[$sizes[2]]))
        {
                $imagecreatefrom = 'imagecreatefrom' . $default_formats[$sizes[2]];
                if ($src_img = $imagecreatefrom($destination))
                {
                        resizeImage($src_img, $destination, imagesx($src_img), imagesy($src_img), $max_width === null ? imagesx($src_img) : $max_width, $max_height === null ? imagesy($src_img) : $max_height, true, $preferred_format);
                        $success = true;
                }
        }

This will call `imagecreatefrom` + extension, ie `imagecreatefrompng` with invalid data. It's just plain dumb. Tell a library that this is a PNG and hand it something else, expect things to break.

The solution here is to actually open the file and read the header to determine it's type. I am in the middle of writing a fix in now

[magic]

And what if I take a BMP file and patch the PNG magic number into it?
Calling wrong function is one thing, the library being rubbish and failing to sanitize untrusted input is another

[gnif]

That's just it, the library is not failing, it's doing exactly what it's supposed to. The issue is that it's slow at it, and consumes a ton of ram, hitting the PHP limits and it gets terminated.
A highly compressed PNG with large dimensions will do exactly the same thing.

> And what if I take a BMP file and patch the PNG magic number into it?

gd will bomb out and stop, the issue is that GD can and will load a BMP as it's a generic image processing library that PHP wraps.

At it's core, the issue is SMF's poor design, image thumbnail generation should be a background task done by the server, NOT as part of a HTTP request.

[magic]

This function should return an error when it's presented with a BMP file, not eat RAM like crazy. A BMP is not a highly compressed PNG.

the issue is that GD can and will load a BMP as it's a generic image processing library that PHP wraps

Does that mean that uploading the very same BMP with BMP extension causes the same problem?
Because if not, that's still a bug in libgd's PNG loader, rather than any problem with BMPs.

[gnif]

>Does that mean that uploading the very same BMP with BMP extension causes the same problem?
>Because if not, that's still a bug in libgd's PNG loader, rather than any problem with BMPs.

No idea, feel free to debug this and chase it with them. Simple fact of the matter is, we need a fix now. Fixing this issue is already well beyond the scope of the services I render for dave as it is.

[bd139]

It's definitely libgd's fault. A DoS attack from malformed input is definitely CVE-worthy. It should return E_WHAT_THE_FUCK_DID_YOU_GIVE_ME error or something if it can't parse the file.

Workaround....

Assumption: this is a FPM process or something running with nginx in front of it. Issue is memory ballooning

1. Set proper memory limits in systemd for the FPM process. See: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LimitCPU=
2. Set systemd to auto restart the FPM process: Restart=always
3 (optional but recommended): run more than one FPM instance and use nginx as a balancer so that if one fails there's more left.

This will mean if it does crash or start gobbling RAM it'll restart.

Edit: can someone send me the file? I'll create a marketing web site for it "phpb0rk" and make £50k from selling it to some terrorists in NK 

[gnif]

This will mean if it does crash or start gobbling RAM it'll restart.

Why do you think the site didn't die? Solutions/protections for these issues are already in place. It doesn't however stop a bunch of people consuming all available PHP processes because of a "slow page load" hitting refresh.

[bd139]

Well it's hard to debug from the outside. I'm pissing in the dark here

Add more cycles is about all you can do then.

[magic]

I did a quick test on a Debian 10 system with PHP 7.3.19. Not sure how to test libdg version, I don't have root on that box and can't find a file like that in /usr/lib.

Code: [Select]

<?php
$i=imagecreatefrompng("test.bmp");
for(;;);
?>
PHP Warning:  imagecreatefrompng(): 'test.bmp' is not a valid PNG file in
Standard input code on line 2
^CMemory usage didn't increase at all after hitting CTRL+D to execute the typed code. Maybe I need some special BMP file, maybe it's fixed in this version.
Memory usage did increase a few megs if I used frombmp instead or converted the file to PNG.

So dunno, check if everything is up to date and pray that there are no serious vulns in there, I guess.

[bd139]

It's probably a broken BMP file that just happens to skip whatever validation is. It might even be intentionally malformed. I hope your FPM is running as an unprivileged process 

To note libgd has a hell of a lot of CVEs against it which are similar: https://www.cvedetails.com/vulnerability-list/vendor_id-6668/Libgd.html

[magic]

Well, I could try to upload my test.bmp here as killeevblog.png and see what happens

[bd139]

 

Really to debug this we'd need:

1. PFP FPM version
2. OS version
3. Libgd version
4. Exploding BMP of doom.
5. Probably about 3 hours of pain

[gnif]

1. PFP FPM version
2. OS version
3. Libgd version
4. Exploding BMP of doom.
5. Probably about 3 hours of pain

Not going to happen for obvious reasons.

Please though stop posting about this here as this topic is special and I am alerted to responses to this topic. It's intended for actual outage reports.

[mansaxel]

Yup,

Issue fixed, another windows bitmap uploaded with a png extension. SMF goes nuts trying to load it and just hangs consuming tons of RAM.

Code: [Select]

FILE(1)                   BSD General Commands Manual                  FILE(1)

NAME
     file -- determine file type

<snip>

     The magic tests are used to check for files with data in particular fixed
     formats.  The canonical example of this is a binary executable (compiled
     program) a.out file, whose format is defined in <elf.h>, <a.out.h> and pos-
     sibly <exec.h> in the standard include directory.  These files have a
     ``magic number'' stored in a particular place near the beginning of the file
     that tells the UNIX operating system that the file is a binary executable,
     and which of several types thereof.  The concept of a ``magic'' has been
     applied by extension to data files.  Any file with some invariant identifier
     at a small fixed offset into the file can usually be described in this way.
     The information identifying these files is read from the compiled magic file
     /usr/share/file/magic.mgc, or the files in the directory
     /usr/share/file/magic if the compiled file does not exist.

<snip>

HISTORY
     There has been a file command in every UNIX since at least Research Version
     4 (man page dated November, 1973). 


Why does SMF degrade itself to using MS-DOS heuristics, when this is and has been available for some time?

[joeqsmith]

In the last few days I have notices that some PNG files captured with snippet fail security.  It seems to be hit and miss.   

[jchw4]

One of my JPGs failed security test too.
Could somebody explain what it means?

Upd: It's interesting that recoding it into .png did not help.

Upd1: Switching off "Progressive JPEG" option did help 

[McBryce]

I've found that all pictures saved with the 64bit version of irfanview fail, but if I save them using Photoshop or MSPaint they get through.

McBryce.

[SilverSolder]

Just wait till the security software gets smart enough to actually look at the pictures! 

[Yansi]

Just wanted to let you know and confirm the above, there seems to be a bug in the "attachment security check", as now out of nowhere, some JPG files seems to be failing the check. And nothing has changed on my software side of things for years, I still use the same software to process JPG (or any) mages. Yet now they seem to fail randomly. And I am pretty sure, the file is clean of any kind of malicious sh!t.

[McBryce]

Yes, but it's not just this forum. Other forums that use the same software are experiencing the same issue.

McBryce.