4 ms·
A nice middle ground would be to change to have this unexpected code path require explicit invocation via a command line flag or enablement through an env varia
by awirth 9y ago
A nice middle ground would be to change to have this unexpected code path require explicit invocation via a command line flag or enablement through an env variable. This would reduce the attack surface for the vast majority of users and still retain support (albeit not entirely backwards compatible with scripts) for folks that want this.
> Poorly tested obscure format support is a goldmine for hackers looking for exploitable code.
IMO the issue is when these code paths are automatically invoked. This is how you get gstreamer running 6502 opcodes for a codec no one has ever heard of when you download a file from the internet.
- vanderZwan 9y ago> This is how you get gstreamer running 6502 opcodes for a codec no one has ever heard of when you download a file from the internet. Ok, I'll bite: context?
- tekromancr 9y agoiirc, it has to do with gstreamer's support for chiptunes in their native format. There is basicly a nes emulator built in.
- lmm 9y agohttps://scarybeastsecurity.blogspot.co.uk/2016/11/0day-exploit-compromising-linux-desktop.html https://scarybeastsecurity.blogspot.co.uk/2016/11/0day-explo...
- deleted 9y ago[deleted]
- developer2 9y agoI don't see how a command line flag or environment variable helps to reduce the attack surface. If an exploit is found, any attacker can add the required flag or environment variable anyway.
- adrianN 9y agoNot in all cases. For example if you find a bug in some obscure imagemagick code you can exploit it by just having the user download it and look at the download folder in a file explorer that produces thumbnails using imagemagick. If support for that obscure format would require explicit enabling, most likely the user would see some generic icon instead of getting their hard disk encrypted.
- cesarb 9y agoOnly if the attacker controls the command line or the environment. Suppose you have a shell script which does something like "blah ... | gunzip > somewhere", where input to the "gunzip" step is under control of the attacker. Requiring a command line flag, or even an environment variable, would be enough to avoid exposing the code in question to the attacker-controlled input. Usually, it would be too late to add a new command line flag, since people might have scripts which depend on being able to unpack files without passing that flag. In this case however, since it was broken for years and nobody else complained, it's very probable that nobody actually depends on this feature working, so requiring a new command line flag or even removing the feature would not cause many problems.
- developer2 9y agoAh, agreed. Hadn't considered that case. Thanks.
- katastic 9y agoExcept that's not at all related. 6502 was added not because it's legacy, but because it was a feature. It wasn't added in 1973 and "kept" for decades.