answer to reported bug?

Started by mt, November 10, 2014, 07:42:01 AM

Previous topic - Next topic

mt

Hi
I reported last week a proof of a bug in the theme zip unpack algo of smf and the resulting potential (even when unlikely in real) 0-day bug.

I got no feedback so far.

Has the team got and understood the reported issue?

Thanks
MT
Daimonin MMORPG

Illori

assuming you mean the security report that was made? you should not report bugs to the security report.

take a look at http://www.simplemachines.org/community/index.php?topic=465882.msg3254680#msg3254680

Arantor

I am certain the team has received it.

The real question: can you weaponise it? Can you actually do something tangible with it? If you're talking about a proof of a bug in the unzip algo, you're talking about a flaw in gzinflate and inherently in libzlib. Which can't readily be fixed.

If you're saying what I think you're saying, though, you're talking about trying to find a way to compress data such that it gets decompressed into a possibly dangerous form. The thing Illori is reporting is different to an actual 0-day bug though and I suspect not the thing you're trying to report.

The effort required to pull that off is insane, compared to the fact there are much, much simpler ways to achieve anything. One does not spend many hundreds of man hours creating a dangerous theme that looks legitimate when it is much simpler to create a theme that is dangerous but socially engineering their way past the review process.

Or indeed, socially engineering their way to get the admin credentials. Or indeed pretty much anything other than actually doing what you're suggesting could be done, even if it could be done in a feasible timescale.

mt

The real question is why no one contacted me where i asked for after i figured out that bug (which triggers only for some rare data) and created some example zips with bug description and uploading that stuff to show you that effect. I costed me some time. And i am to old that i like to waste time.

I send you a PM, you can check it for yourself then. I want delete that zips, thats it.


Kindred

yes. We received the report.

No, it is not remotely triggerable as a 0-day hack - and even if it was, you would need to have admin access to the forum in the first place.
it is a small bug that is unusual but may occur if the user extracts and then re-zips a theme package before upload (depending on the archiver program the user uses) but it is not a hack or security issue.

http://www.simplemachines.org/community/index.php?topic=465882

We will probably address it in 2.1 and possible the next release of 2.0.x, but it does not require an immediate security release.

I am sorry that no one contacted you...   but we are in the midst of preparing for the beta release of 2.1, so things are a little busy on the dev side right now.
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Arantor

Having taken a look at the report now, I agree with the assessment above. You can't do anything particularly useful with it, you can't practically weaponise it, meaning that you're talking about a known defect rather than anything that is actually a security issue.

I suspect that it simply fell through the cracks with the housecleaning previously that occurred in this board.

mt

Well, as i said - unlikely. But the point is that you get something abnormal in a public accessible point of your server. That is a no go.

And that the file had different data inside depending on the zip file is another bad sign. Its not just a destroyed file. The content differs
depending how the "bad" zip file is packed. I saw at last 3 different data sets written back in my testings.

I would be careful with the assumption that it can't be used.
To assume security is the wrong way.

Arantor

I am way more paranoid than most about security.

SMF is comparing the values internally listed in the zip file for 'actual size' vs 'compressed size', notices there's a difference (because of store vs deflate for images) and tries to gzinflate, even when it's not gzcompressed.

To reproduce this in a dangerous way:
1. Create dangerous file
2. Gzdeflate it
3. Create a zip file that has specifically modified checksums - but *still* manages to have other legitimate checksums - in other words, intentionally managing to create a zip file with crc32s that are exactly what you need them to be
4. Convince an administrator to upload and install

Why would you do all of this when you could, much more easily, just perform step 4?

mt

I am not sure what you guys mean with repacking etc.

You can't create with the debian wheezy standard zipper a valid theme which includes the pictures in my demo zips.
At last not without using special packing formats i did not tested.

A "zip -r mytheme.zip [nofollow] mytheme" where that 4 pictures i submited are included will always create a valid and normal zip file which can't be decoded right by smf.

There is a marker on it or a combination of it which will bug out smf . Always. Other pictures stored next to them in the 100% same way are fine.

Copy them to 1000 other pictures at any position and combination - zip it and that 4 will be written back badly. And when i see it right with different data depending on the included files and positions.

They are always installed destroyed. No exception.

The theory is, that you need to find the right combination of other files and position to make the bad decoded files abusive. In this way hard to abuse in real.
Add one more control element to it we do not even think now about it to harden the control and then things will be different.

Are you really saying that only your very special packing or zipper can create a valid smf theme?

Arantor

No, I'm not saying that. I realise that it's hard to keep up with what I'm saying but please try.

I know, for example, that Windows XP's 'create zip' would damage zip files, while 7-zip would always make 100% working zip files. (I've been observing this for years)

In practicality, abusing this flaw to do anything dangerous requires so much work it's simply not worth the effort. Yes, dodgy data is generated on the server - point is it is just corrupt data. Actually doing something serious with it is so unlikely it's simply not worth it.

What we have here is a minor bug that only affects a small number of people in practice (since it only affects mod or theme authors when making the files for distribution; it doesn't affect the vast majority of people who just consume content)

mt

There is a reason i did the test under debian. I do not think we should question the debian zip tool.

I can't understood you guys not to fix this. Its not only a enoying bug,

Its complete pointless to talk about the risk chance. 90% of the "bugs" fixed in linux are even in the simulation hard to trigger.
But because no one can make a determinated assumption about the real risk they are all handled like "possible".

You should do the same.
If that bug is really a only a glitch and easy to understood then its also easy to fix.
What was the problem to fix it when it was known since january? With 2.0.9 out some weeks ago was an easy chance to remove it.
Yes, i know. Open source and all. But there was plenty of time. We talk here about 8 month.


Arantor

QuoteIts not only a enoying bug,

Yes it is only an annoying bug. Given that I am one of the most prolific authors of things (and have encountered the issue you refer to - 5 years ago), I am well aware of just how 'annoying' or 'serious' this is. Better than most.

QuoteIts complete pointless to talk about the risk chance. 90% of the "bugs" fixed in linux are even in the simulation hard to trigger.

There is a world of difference between a kernel and a usermode application. I also remember having many many conversations with Cleo back in the day which lead to Atrinik being a thing, so you really have no high horse to stand on here, over things you refused to fix in Daimonin, on the same order of severity as this one actually is. (I cannot remember the specifics, nor can I be bothered to dig out the logs etc, however)

QuoteBut because no one can make a determinated assumption about the real risk they are all handled like "possible".

Sure it's *possible*. It's just so ridiculously unlikely that it's not worth fixing as a security matter. This is, essentially, like tightening a slide bolt 'for security' when a door might be otherwise unlocked; there is such a thing is ignoring the bigger picture.

QuoteIf that bug is really a only a glitch and easy to understood then its also easy to fix.

It is only a glitch but it is not easy to understand. And the fact that it has been known for years is indicative of the complexity to fix.

QuoteWhat was the problem to fix it when it was known since january?

It's been known since before 2.0 went stable - and no-one managed to figure out a fix since then.


Seriously, thank you for your time in reporting this but honestly it isn't going to be changed at this point, please let this one drop - it is not a security issue despite any assertions to the contrary.

You've already had the SMF project manager telling you this - I can ask one of the SMF devs to weigh in on this matter too but I don't expect they will give you a different answer.

Advertisement: