Feature request: security-focused changes for stb_vorbis and stb_truetype

[ell1e]

Is your feature request related to a problem? Please describe. It would be nice if some time in the future, security-focused changes could come to stb_vorbis and stb_truetype. stb_image already has a maximum image size which is absolutely necessary to avoid crashing a program on an arbitrary untrusted image, but stb_vorbis seems to happily try to allocate near unlimited data item sizes with no such boundary set in place by default. Even worse, stb_truetype seems currently designed to make each program a completely remote controllable backdoor if loading the wrong font. This design makes these libraries unusable for many use cases. I understand security holes will continue to exist anyway, but it still makes a difference whether a library at least tries to plug the obvious holes or basically openly hands over the keys to any slightly suspicious file like stb_truetype apparently does.

Describe the solution you'd like All libraries that load external files should have reasonable memory allocation limits (like, maximum size) set by default and an option to change that, at the very least as a compile time define. All libraries should be designed to at least try to avoid all possible memory errors (overruns, invalid access, ...) from untrusted files. If this were ever possibly added in the future, it would greatly increase the possible use cases these libraries could be used for, which I think would be nice. E.g. for a document viewer, stb_truetype can't really be used right now since a user wouldn't understand how dangerous that is, which is sad. It would be cool to be able to use it more widely.

Describe alternatives you've considered There doesn't seem to be an alternative other than using different libraries entirely. I mean there's sandboxing, but usually that's only a 2nd line of defense and may not be strong enough to fend off things when basically arbitrary attacker code execution is more or less allowed by policy to start with.

Additional context

[nothings]

The stb libraries originated in a game development environment where the program author had secure control over the inputs. While we are gradually taking steps to improve security, it isn't the highest priority, and programmers are welcome to use other libraries instead.

[ell1e]

I mean that's fair, I was just hoping to provide a nudge (or maybe I'll get around to some pull requests even?). Even for games for what it's worth, many with multiplayer components allow custom maps downloaded in-game with a quick prompt with custom assets from whomever strangers, so it can still be extremely relevant there.

I'm curious, is stb_vorbis written with the intent of not corrupting or buffer overflowing on malicious input at this point? I know it has the malloc exhaust issue but that seems like a much lesser danger than complete remote control. Or is it also more in an stb_truetype state where nothing's really safe? The code at least looks like it tries to do some verification.

[nothings]

stb_image has received the most work and STILL has outstanding security issues, so.

[ell1e]

Ah, so that one is getting there at least? That's super nice to hear! Thanks for the detailed update. (I assume that means you think stb_vorbis is currently likely about as unsafe as stb_truetype at this point in time.)