WUFFS
WUFFS
Posted Oct 12, 2023 16:07 UTC (Thu) by pizza (subscriber, #46)In reply to: WUFFS by tialaramex
Parent article: Remote execution in the GNOME tracker
> Everybody (phone vendors, browsers, and in this case Linux desktop environments) needs to stop trying to use "sandboxes" for their own code rather than just using provably safe techniques so it's faster and not ridden with security holes.
Sure, for a _new_ parser it's logical to use more modern tooling for parsers and other sensitive code. Meanwhile, in the real world, WUFFS' first (public) commit was in April 2017 versus June 2004 for libcue. How dare its authors not have a time machine!
So unless you're volunteering to write (or fund) a new parser using wuffs, and update all of the applications that use libcue to use this new parser... oh, and multiply that by the hundreds of other parsers out there and the tens of thousands of applications that use them...
That's why sandboxes are used; it allows vastly improved safety _today_ with old code, while you wait for safely-rewritten stuff to be usable. If ever.
Posted Oct 12, 2023 17:42 UTC (Thu)
by Tobu (subscriber, #24111)
[Link] (1 responses)
Posted Oct 13, 2023 8:07 UTC (Fri)
by epa (subscriber, #39769)
[Link]
Posted Oct 12, 2023 18:16 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (4 responses)
Part of the problem, though, is a false sense of security. People believe their sandbox will protect them, so they don't bother to do other things like rewriting in a safer language. It's a general problem with defense in depth strategies. Anyone without exceptional discipline tends to relax because someone else is taking care of the problem. The net result is you wind up with much less security than you'd expect because the individual layers are less effective than they would be in isolation. This is by no means limited to computers. You see it anywhere this kind of layered defense approach is used.
Of course this is an obscure library for an obscure format that hasn't been very relevant for a while, so it's quite possible it would never get updated until someone found a security hole. If that's the case, maybe it shouldn't be installed by default. It seems like a good case for reducing attack surface by installing fewer libraries. The system should be able to ignore files in unknown formats, so not installing libraries for unused formats would just result in files from those formats being skipped. People who install libraries to deal with .cue files would still be vulnerable, but anyone who doesn't need that feature would be protected.
Posted Oct 12, 2023 18:44 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
Yeah. I think, including the fix to this flaw, there have been five commits in the past six years.
> If that's the case, maybe it shouldn't be installed by default. It seems like a good case for reducing attack surface by installing fewer libraries.
The software using the library would need to be partially rewritten to dynamically load these parsers at runtime and gracefully handle them not being present.
Either way, it's a change in requirements leading to a change in design and [re-]implementation. None of that comes for free.
Posted Oct 12, 2023 19:36 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (1 responses)
I just assumed it was already designed that way. If it isn't, I agree it's a big architectural change. In addition to being a lot of work, it might cause more problems in the short term by creating new security bugs.
Posted Oct 13, 2023 9:08 UTC (Fri)
by Tobu (subscriber, #24111)
[Link]
Looking at the Ubuntu package, there is some modularisation; /usr/lib/x86_64-linux-gnu/tracker-miners-3.0/extract-modules/libextract-disc-generic.so handles cue sheets specifically and can be moved out of the way. However, /usr/lib/x86_64-linux-gnu/tracker-miners-3.0/extract-modules/libextract-gstreamer.so also links libcue, plus I'm sure gstreamer does its own module loading, and libgmodule is also linked. I doubt the gstreamer bits were built with sandboxing in mind.
Posted Dec 2, 2023 20:06 UTC (Sat)
by ssokolow (guest, #94568)
[Link]
Bear in mind that BIN/CUE is the standard way to represent optical discs with audio tracks (when you don't need to capture subchannel data, physical data track wobble, or other low-level encoding details that copy protection schemes check), as used by tons of emulators including DOSBox. It's not a highly visible format in modern systems, but it's hardly obscure. (eg. GOG.com re-releases of DOS games with CD audio which don't use ScummVM will use an ISO file for the data track, typically renamed
Posted Oct 14, 2023 5:40 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
If only people were not still writing brand new parsing code in bare C in 2023...
Firefox's RLBox+wasm2c integration is a good path to sandboxing existing libraries (that need limited platform support; parsers such as this): compile the library to WASM and back to C (wasm2c), now whatever corruption is inside it can't escape some linear address space. Don't trust the outputs, here they are just going into an index which seems safe.
WUFFS
WebAssembly
WUFFS
That's why sandboxes are used; it allows vastly improved safety _today_ with old code, while you wait for safely-rewritten stuff to be usable. If ever.
WUFFS
WUFFS
The software using the library would need to be partially rewritten to dynamically load these parsers at runtime and gracefully handle them not being present.
WUFFS
WUFFS
.gog to avoid "I mounted this and I got no music" tech support calls, a bunch of Ogg Vorbis files, and a version of DOSBox with the patch to support Ogg Vorbis audio tracks in .cue files. I imagine Steam re-releases would do something similar).WUFFS