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
I don't think that works though, we have a lot of problems due to shitty 90s code that nobody figured would be attacked but here we are
1
Plenty of it is 2016 code too. Also, even if SQLite wasn't meant to be used as an application / data transfer format, it's certainly still an attack surface. An attacker able to drop files into an app data directory via an exploit like zip extraction shouldn't get code exec.
1
One of the basics of security is not having code that is writable. The same goes for not unnecessarily trusted persistent state. An embedded device with an internal SQLite database not exposed to anything still cares about the security of SQLite handling the file format.
1
Since an attacker that exploits the device should not be able to persist access on the device, by having all code / core data verified and avoiding trust in the persistent state. At most, they should be able to persistently brick it without coming up with a longer exploit chain.