File formats are the buffer issue honeypot. You may be aware of how often video and audio codecs have vulnerabilities - it's nearly never the hand-tuned frame decode assembly (where you would think all the mistakes would be). It's nearly always the thing that reads the metadata and encoded frames to memory. Binary formats have things like offsets in them, and those can be trivially used to overrun.
Same thing applies here. Even Rust has a crate for dealing with binary data, despite its memory promises: https://crates.io/crates/untrusted
It's a fucking minefield, and this is one area where the Rust zealots are undeniably correct. It doesn't have to be Rust, any memory safe language will do, but Rust also happens to be performance competitive and that's usually also desirable.
The technology you want for this sort of work is WUFFS, for Wrangling Untrusted File Formats Safely.
Rust is a general purpose programming language, which is great if your problem might be something never imagined before, but this literally isn't our first rodeo, we have wrangled lots of file formats before, we should use a language purpose-built to do that safely.
I think the claim is hyperbolic, since most people memory-unsafe PDF implementations, but PDF is a monster format, a metaformat that brings in virtually every conceivable display format, and their renderer implementations with them, often poorly-maintained, never-touched reference implementations from the before times. PDF is pretty scary.
PDFs are usually untrusted input and C provides no assurance there isn't a bug in the code that allows corrupted input to turn into arbitrary remote code execution.
very VERY few people judge tools like this by the language used to develop them.
How many people judge their tools based on the AES key entropy?
A lot actually.
You're confusing just assuming by default its enough for purpose rather than not caring at all.
just down vote it.
You can downvote anything not interesting.
If he have list some alternative or give example, it might be interesting.
What are the alternatives?
PDF.js, for example. It's what Firefox uses, and most websites with integrated on-page PDF viewing functionality.
Genuine question, since I'm not very knowledgeable about this: why is using C for a PDF tool such a bad idea?
File formats are the buffer issue honeypot. You may be aware of how often video and audio codecs have vulnerabilities - it's nearly never the hand-tuned frame decode assembly (where you would think all the mistakes would be). It's nearly always the thing that reads the metadata and encoded frames to memory. Binary formats have things like offsets in them, and those can be trivially used to overrun.
Same thing applies here. Even Rust has a crate for dealing with binary data, despite its memory promises: https://crates.io/crates/untrusted
It's a fucking minefield, and this is one area where the Rust zealots are undeniably correct. It doesn't have to be Rust, any memory safe language will do, but Rust also happens to be performance competitive and that's usually also desirable.
The technology you want for this sort of work is WUFFS, for Wrangling Untrusted File Formats Safely.
Rust is a general purpose programming language, which is great if your problem might be something never imagined before, but this literally isn't our first rodeo, we have wrangled lots of file formats before, we should use a language purpose-built to do that safely.
3 replies →
I think the claim is hyperbolic, since most people memory-unsafe PDF implementations, but PDF is a monster format, a metaformat that brings in virtually every conceivable display format, and their renderer implementations with them, often poorly-maintained, never-touched reference implementations from the before times. PDF is pretty scary.
PDFs are usually untrusted input and C provides no assurance there isn't a bug in the code that allows corrupted input to turn into arbitrary remote code execution.
Other than Ada/SPARK, which languages can guarantee this won’t happen?
2 replies →
buffer overflow vulnerability in code dealing with user generated data and a complex file format.