Or heck, .doc or .psd, which are basically just memcpy’d internal structures of Word and Photoshop respectively.
Conversation
That's basically XCF too.
github.com/GNOME/gimp/blo
They're collaborating with the Krita developers to make en.wikipedia.org/wiki/OpenRaster as a replacement. It's probably going to be even more complex though since they're going to want to add more capabilities.
1
2
The solution to the problem cannot be not making this kind of software, or somehow getting users not to exchange media files, image editing files, word processor documents, etc. Really just parse the file format in a memory safe language without dynamic code execution.
1
5
And that memory safe language can certainly be a subset of C with annotations / rules that make it memory safe. No problem with that, I just don't think it's a very useful/practical thing to do personally since I'd rather use a nicer language if it has to be from scratch anyway.
1
1
We know how to write software with decent security and these kinds of capabilities. It's not a mystery. We choose to use software architectures and languages making it unrealistic to provide decent security. Even if you claim that it's due to programmer incompetence, not tools...
1
2
3
... then clearly there are near 0% competent C programmers. The whole point of safer tooling is that humans aren't being trusted to never make a mistake or miss something. It's extremely hard to right completely correct software and those bugs should not be remotely exploitable.
2
2
5
You only need to be highly competent at C if you're writing attack surfaces. Otherwise you just need to be very clear that your code is not intended to be used anywhere where it's an attack surface.
3
Such code is even usable with untrusted data, if you run it in a safe privilege context. For instance seccomp sandbox, container sandbox, wasm, a virtual machine, ...
1
... unless it can communicate back to the attacker, in which case you can use that RCE to exfiltrate data via side channels, no?
1
Obviously it has access to any bugs, including hardware-level ones, in whatever sandbox model you use. But cross-process Spectre etc. are possible to mitigate completely. You can also deny access to time to make them all impossible.
1
An attacker with arbitrary native code execution is in a powerful position even within a very tight sandbox. That's drastically more attack surface than a well implemented file format handling library which can of course be used inside a sandbox just like an insecure one.
Spawning a fresh sandboxed process for every single file is needed if that's the only way you implement a security boundary too. Reusing a sandboxed renderer across security boundaries (different files) is bad since they can insert evil data elsewhere.
1
2
Processes are ridiculously cheap. A few microseconds. It's the startup of awful runtimes, not process creation or execve, that's expensive.
1
1
Show replies