Author Topic: 7-zip vulnerability - update now  (Read 994 times)

0 Members and 1 Guest are viewing this topic.

Offline bingo600Topic starter

  • Super Contributor
  • ***
  • Posts: 2041
  • Country: dk
 
The following users thanked this post: thm_w, iMo

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15835
  • Country: fr
Re: 7-zip vulnerability - update now
« Reply #1 on: November 25, 2024, 10:18:04 pm »
There's something I dont get in this article.
They mention Zstd, which is indeed used in various critical parts of Linux and other systems, but Zstd is not 7-zip and not provided by 7-zip AFAIK.
Can anyone enlighten me?

 

Offline sleemanj

  • Super Contributor
  • ***
  • Posts: 3052
  • Country: nz
  • Professional tightwad.
    • The electronics hobby components I sell.
Re: 7-zip vulnerability - update now
« Reply #2 on: November 25, 2024, 10:57:11 pm »
There's something I dont get in this article.

My readings is that the bug is in 7-zip's particular implementation of Zstd.

https://github.com/mcmilk/7-Zip/blob/14d4b3f5e43e1c9bf23d314dcb8fb76887f6e855/C/ZstdDec.c




~~~
EEVBlog Members - get yourself 10% discount off all my electronic components for sale just use the Buy Direct links and use Coupon Code "eevblog" during checkout.  Shipping from New Zealand, international orders welcome :-)
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15835
  • Country: fr
Re: 7-zip vulnerability - update now
« Reply #3 on: November 25, 2024, 11:16:22 pm »
Ah thanks, is the 7-zip's zstd decoder really used in anything critical in Linux? I sure wasn't expecting that. Maybe that is so?

I looked at what seems to be the culprit:
https://github.com/mcmilk/7-Zip/commit/14d4b3f5e43e1c9bf23d314dcb8fb76887f6e855#diff-896855d0e24931a930fa2e2a5e6c4a92d3589a70c1f8436d76e0f3c673888624
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 4044
  • Country: us
Re: 7-zip vulnerability - update now
« Reply #4 on: November 26, 2024, 03:18:30 am »
Ah thanks, is the 7-zip's zstd decoder really used in anything critical in Linux? I sure wasn't expecting that. Maybe that is so?

Not that I can tell.  I think the article was just weirdly written.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15835
  • Country: fr
Re: 7-zip vulnerability - update now
« Reply #5 on: November 26, 2024, 06:03:59 am »
Ah thanks, is the 7-zip's zstd decoder really used in anything critical in Linux? I sure wasn't expecting that. Maybe that is so?

Not that I can tell.  I think the article was just weirdly written.

Ok, thought so. It sounds as though the vulnerability was blown out of proportion.
 

Online JohanH

  • Frequent Contributor
  • **
  • Posts: 674
  • Country: fi
Re: 7-zip vulnerability - update now
« Reply #6 on: November 27, 2024, 10:42:38 am »
Ah thanks, is the 7-zip's zstd decoder really used in anything critical in Linux? I sure wasn't expecting that. Maybe that is so?

Not that I can tell.  I think the article was just weirdly written.

Ok, thought so. It sounds as though the vulnerability was blown out of proportion.

Probably, but better safe than sorry. This video goes to some extreme debugging of the issue, but comes out unclear if the issue is a clear danger or not. However, always best to update, because the memory overflow is fixed in the latest version.

 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 4044
  • Country: us
Re: 7-zip vulnerability - update now
« Reply #7 on: November 28, 2024, 02:41:29 am »
Probably, but better safe than sorry. This video goes to some extreme debugging of the issue, but comes out unclear if the issue is a clear danger or not.

I don't think the severity is exaggerated, anyone using 7zip should definitely update to fix this.  But the scope was exaggerated at least by implication they possibly any use of the Zstd algorithm are at risk while the vast majority of Zstd uses are not vulnerable.

I don't actually think exaggeration was the intent.  In context the article reads like someone wrote a 5 line article that had all the actual information then someone else came along and decided they needed to "add context" and did a quick Google search of "uses of Zstd compression". 
 
The following users thanked this post: JohanH

Offline gmb42

  • Frequent Contributor
  • **
  • Posts: 307
  • Country: gb
Re: 7-zip vulnerability - update now
« Reply #8 on: November 28, 2024, 01:33:28 pm »
And although I've used it for a long time, I only just noticed this week that the Windows versions of the installer and binaries are NOT signed and the developer has apparently no interest in doing so.

Sigh.  Now have look for a replacement that is signed.
 

Online JohanH

  • Frequent Contributor
  • **
  • Posts: 674
  • Country: fi
Re: 7-zip vulnerability - update now
« Reply #9 on: November 28, 2024, 03:18:32 pm »
And although I've used it for a long time, I only just noticed this week that the Windows versions of the installer and binaries are NOT signed and the developer has apparently no interest in doing so.

Sigh.  Now have look for a replacement that is signed.

If you need an authenticode (code signing) signature, yes, there's a cost associated with that. That's why smaller open source projects don't often sign Windows binaries. Unless you have a trusted third party signing it for you, I wouldn't trust the authenticity of the software (someone could have modified the software before signing). Best would be to compile and sign yourself in that case.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 15835
  • Country: fr
Re: 7-zip vulnerability - update now
« Reply #10 on: November 28, 2024, 09:17:06 pm »
Probably, but better safe than sorry. This video goes to some extreme debugging of the issue, but comes out unclear if the issue is a clear danger or not.

I don't think the severity is exaggerated, anyone using 7zip should definitely update to fix this.  But the scope was exaggerated at least by implication they possibly any use of the Zstd algorithm are at risk while the vast majority of Zstd uses are not vulnerable.

I don't actually think exaggeration was the intent.  In context the article reads like someone wrote a 5 line article that had all the actual information then someone else came along and decided they needed to "add context" and did a quick Google search of "uses of Zstd compression".

Sure, now that you're aware, do update. It doesn't cost anything either.

But yes, it was greatly exaggerated. Not only can it happen only if you use 7-zip (which definitely not all people do, especially on Linux), but only if you use it to decompress zstd-compressed files, which would be even more of a niche case, as there are other tools more standard on Linux for doing just that. Let me know the last time you used 7-zip to uncompress zstd.

On Windows, 7-zip (with its associated GUI) is more often used as a general-purpose tools for all major compression formats, so on Windows that could be riskier. But even so, when again was the last time anyone here, on Windows, used 7-zip to decompress a zstd file?

So, making hours-long videos on the topic and worrying articles with false information (whether intended or not) on it, yes that's more clickbaity than useful. Just MHO.

Back to the technical aspect of it, I've posted a link to what appeared to be the culprit and the fix - essentially an integer wrap-around due to using too narrow an integer type - but looking closely at the corresponding function, I still don't get what the problem is. If anyone has and can explain in more details. The CVE doesn't detail it either AFAIK. As a small side-note, I didn't particularly care for all the custom-defined integer types there are in 7-zip's source code. Not even using stdint's from C99 for software in 2024 is pretty questionable to me. Sure it may have historical reasons (it was first released in 1999), but they had like 25 years to refactor that. Oh well. And it turns out that the issue was fixed by using "unsigned" as a type (not even "unsigned int"), which is technically equivalent to "unsigned int" but looks very much like C from the 70's to me. A detail, but doesn't really bode well and if that were me, I would suggest some refactoring of the code base.



 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf