LWN: Comments on "Remote execution in the GNOME tracker"

WUFFS

ssokolow — Sat, 02 Dec 2023 20:06:04 +0000

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 .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).

Remote execution in the GNOME tracker

roblucid — Thu, 26 Oct 2023 10:44:01 +0000

Languages like python don't have fixed width integers, as they're unnatural and cause "edge cases (bugs)" so a bignum library is used.
Using unsigned specifies modulo arithmetic with clear semantics; advocating signed is saying you want programs that when overflow guards fail have undefined behaviour.
A compiler can know that c = 128+128 is > 0 because if it isn't your program is defective, you failed to use the right signed type.

Remote execution in the GNOME tracker

mathstuf — Tue, 24 Oct 2023 11:29:09 +0000

> (e.g. Bluetooth audio - pointers gratefully received(!))

AFAICT, this is handled by Pulseaudio/Pipewire automatically. There is `blueman-manager` for GUI management of devices, `pavucontrol` for routing audio, and `bluetoothctl` for command line control. Works for me under XMonad (and all the "automatic setup" that such a choice usually implies doesn't happen).

Remote execution in the GNOME tracker

sammythesnake — Mon, 23 Oct 2023 09:01:41 +0000

[comedically large number]%

One of the motivations for me to switch to swayWM was that my patience×Google+fu×brainpower product was significantly short of the threshold required to get rid of tracker which I never used...

These days, I have to use that resource on getting stuff done that a heavier WM/DE would do automatically (e.g. Bluetooth audio - pointers gratefully received(!)), but at least my weenie laptop isn't constantlyoverheating/chugging/running out of battery (and I'm also a *little* protected from naughty USB dongles)

Remote execution in the GNOME tracker

error27 — Tue, 17 Oct 2023 06:36:55 +0000

"The end-of-loop test just has to be placed before decrementing."

That's just a hack around. The simpler answer is to choose a more intuitive type. Languages like python don't have unsigned variables because they cause edge cases (bugs). Complexity is the opposite of safety. And it's not that hard to add a check for negatives. If people got used to checking for negatives instead of using signedness to save them we would probably be better off. I rant about this at length on my blog:
https://staticthinking.wordpress.com/2023/07/25/wsign-com...

I feel like we would likely have caught this bug in the kernel using static analysis. I would say probably at least 80% chance.

Remote execution in the GNOME tracker

clump — Sun, 15 Oct 2023 18:18:44 +0000

I agree with you and I mean no disrespect to GNOME. I do, however, think there's a bit of room for bug reports and feature requests. A simple way to disable tracker would be most welcome, and myself and many others (perhaps wrongly) feel it's not offensive to ask.

Remote execution in the GNOME tracker

sam.thursfield — Sun, 15 Oct 2023 12:18:07 +0000

This comment is something of a work of art.

Remote execution in the GNOME tracker

tialaramex — Sat, 14 Oct 2023 20:11:36 +0000

feature(unchecked_math) is an unstable feature available in Rust nightly, so, if you actually do this? (Really? OK then) you can go help land https://github.com/rust-lang/rust/issues/85122

My guess is that on real hardware people actually use, Wrapping<i32> has the same performance as the unchecked math does, and likely the same results in many cases, without a scary unsafe marker. But I could be wrong.

I use Wrapping<u32> in my hand rolled implementations of MD5 and SHA1 (not for real software, just for toys) because it's true that wrapping arithmetic is nicer if you know that's what you're doing, but it's defined for i32 as well as u32 and I see no reason to imagine it's a problem on modern hardware.

In fact it reminds me of how f32::from_bits and f32::to_bits are trivial - in principle you could imagine a CPU where getting the raw bits out of a 32-bit floating point value and into a 32-bit unsigned integer is a non-trivial operation. In actuality, every computer you could buy for years now went duh, those are just bits, in the same order, same layout, different meaning, types are just in your head man... Rust reserves the right to actually do hard work to deliver these functions, but in reality on any computer you can buy they're just book-keeping changes, and so they cost zero CPU cycles.

Remote execution in the GNOME tracker

Wol — Sat, 14 Oct 2023 08:15:53 +0000

There's fun, and there's fun.

Developing a project is not easy work - I've tried hard with Scarlet, and with MaVerick before that.

But this particular piece of software is Marmite - and if you make it effectively mandatory when it is (a) resource heavy, (b) considered seriously buggy by a large chunk of your user base, and (c) seen as being of no benefit whatsoever by (maybe the same) large chunk of your user base, you deserve all the brickbats that get thrown at you.

Okay, maybe I'm excessively biased by the debacle that was KDE4 (36 hours and not there yet to boot a desktop that gets shut down nightly???)

Rule 1 of happy developing (yes it's not sufficient, but ...) "Don't piss off your user base with your personal project that doesn't work".

Cheers,
Wol

Remote execution in the GNOME tracker

marcH — Sat, 14 Oct 2023 05:46:09 +0000

> This seems like a really simple request from users that is constantly ignored. I don't understand why.

Isn't GNOME (and any other Linux desktop) mostly developed by volunteers having coding fun? Listening to (sometimes bad) feedback and project managing it is not fun at all.

WUFFS

marcH — Sat, 14 Oct 2023 05:40:20 +0000

> 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!

If only people were not still writing brand new parsing code in bare C in 2023...

Remote execution in the GNOME tracker

NYKevin — Fri, 13 Oct 2023 17:40:22 +0000

We can compare to how Rust does it. Every operation can be performed several ways in Rust:

* Infix notation (i.e. writing something like "a + b" directly): In debug mode, overflow panics (terminates the program with an error). In release mode, it wraps by two's complement.
* checked_foo(): Returns an option type. You can then write separate branches for the "it worked" and "it overflowed" cases. If it overflowed, you don't get a numerical result at all, so while you could panic by calling unwrap(), you can't silently use the wrong number.
* overflowing_foo(): Wraps by two's complement, and returns a bool indicating whether overflow happened. The compiler does not force you to inspect the bool, so this is easier to misuse than checked, but also more flexible.
* wrapping_foo(): Same as calling overflowing_foo() and throwing away the bool. For when you absolutely know that wrapping is correct and there's no alternative code path for it.
* saturating_foo(): Not available for bitwise operations. Returns the value that is closest to the true result. For example, saturating_add(u64.MAX, 1) == u64.MAX, because u64.MAX is the closest representable value to u64.MAX + 1.
* unchecked_foo(): Overflow is UB. Requires an unsafe block, but the compiler emits IR which is equivalent to this function whenever it can prove that overflow will not actually occur, so you really only need this if the compiler isn't smart enough *and* you're trying to squeeze every last cycle out of a tight loop or something like that.

Unsigned overflow in C is already required to be equivalent to wrapping_foo(), so it would be a bad idea to change that at this point. But they could still say that signed overflow does wrapping_foo(), because that's currently UB in C (so no program may validly depend on it), and also because lots of people already compile with -fwrapv anyway. Then they could provide overflowing_foo() as a separate operation (or just treat regular arithmetic as overflowing_foo() and give us some kind of syntax or magic errno-like variable to get the bool value - the compiler can see whether we fetch it or not, so it can decide whether it has to bother preserving that information). Then we have checked and saturating, both of which would be at least somewhat useful to have (so that I don't have to constantly do high-school algebra just to correctly check whether a + b > INT_MAX).

This leaves out unchecked, which I'm fine with leaving out, but I'm sure there's somebody somewhere out there who's counting individual CPU cycles and would want it at least for signed arithmetic. Oh well.

Remote execution in the GNOME tracker

clump — Fri, 13 Oct 2023 12:55:32 +0000

I've been disabling tracker for years, despite it being a required dependency when I use GNOME on Arch or Fedora. Nothing other than its own functionality breaks when it's disabled.

This seems like a really simple request from users that is constantly ignored. I don't understand why.

Remote execution in the GNOME tracker

Wol — Fri, 13 Oct 2023 12:37:03 +0000

> There is unfortunately very little investment in improving desktop search in general, I think for a team of about 1.5 volunteers to keep this 2006-era codebase going way into the 2020's is something quite impressive :)

I hate to say it, but I suspect there is a lot of hostility towards desktop search.

The people who know what's going on hate it.

The people who don't know what's going on don't know how to use it.

The number of people who actually both know about it, and know how to use it, is vanishingly small ...

At the end of the day (and I speak as a database guy) my attitude to much of this is "too much data, not enough information, the signal-to-noise is so poor we shouldn't be keeping all this crap!".

Cheers,
Wol

Remote execution in the GNOME tracker

sam.thursfield — Fri, 13 Oct 2023 10:15:53 +0000

Thanks for the excellent writeup !

If anyone is interested in reading about what features the Tracker search engine & database provides, I did some writeups a few years ago as part of the Tracker 3 effort.

You could start here:

* https://samthursfield.wordpress.com/2020/10/05/tracker-3-...
* https://samthursfield.wordpress.com/2020/11/03/tracker-3-...

There is unfortunately very little investment in improving desktop search in general, I think for a team of about 1.5 volunteers to keep this 2006-era codebase going way into the 2020's is something quite impressive :)

WUFFS

Tobu — Fri, 13 Oct 2023 09:08:49 +0000

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.

Remote execution in the GNOME tracker

NRArnot — Fri, 13 Oct 2023 09:04:55 +0000

I don't even find that things being done in the background without my knowledge to be convenient. On the security front it's disastrous, and it impedes one from learning anything about one's system.

Remote execution in the GNOME tracker

rschroev — Fri, 13 Oct 2023 08:08:40 +0000

I would even argue indexers should be opt-in. They are quite intrusive, and in my experience in general don't even find the thing I'm looking for.

WebAssembly

epa — Fri, 13 Oct 2023 08:07:38 +0000

Compiling to C to WebAssembly, converting back to C, and then compiling to native code… it sure is ingenious. Amazing, though, that it ended up being the most practical way to compile C into “safe object code” where a misindexed array or duff pointer fails cleanly. In fifty years of C compilers the state of the art is still for unsafe by default. If the compiler offered a —safe build mode (whether implemented by WebAssembly or otherwise) you could build most code with that, except performance critical stuff, which CD cue sheets are not.

Remote execution in the GNOME tracker

GoodMirek — Fri, 13 Oct 2023 07:17:44 +0000

I think that there is a big issue contributing to the scale of the problem - there is no simple way to disable the tracker in Gnome.

I used Gnome for several years and remember fighting regular and prolonged high CPU utilization caused by tracker.
It resembled Windows Search - ate my CPU and battery, hard to switch off (actually way harder than Windows Search) and was enabled against my will.

In my opinion, end users should have an easy and convenient way to disable such an intrusive technology. Even better, they should be offered opt-out option during the first Gnome setup.
For me, tracker was always a bloatware.

Remote execution in the GNOME tracker

eru — Fri, 13 Oct 2023 06:27:22 +0000

if you ever need to subtract indices,

You would have to check the range of the result anyway, if doing safe code, and with unsigned indices you only have to check the upper bound. Underflow results in a huge value.

or count backwards.

The end-of-loop test just has to be placed before decrementing.

Remote execution in the GNOME tracker

DemiMarie — Fri, 13 Oct 2023 01:13:23 +0000

What would it take for tracker-sxtract to fork a new process/re-instantiate a WebAssembly module/etc for every file?

That is the only way to have a decent sandbox.

WUFFS

rgmoore — Thu, 12 Oct 2023 19:36:47 +0000

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.

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.

WUFFS

pizza — Thu, 12 Oct 2023 18:44:21 +0000

> 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.

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.

Remote execution in the GNOME tracker

samlh — Thu, 12 Oct 2023 18:19:26 +0000

Firefox does something similar today:
https://hacks.mozilla.org/2021/12/webassembly-and-back-ag...
https://rlbox.dev/

WUFFS

rgmoore — Thu, 12 Oct 2023 18:16:24 +0000

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.

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.

WUFFS

Tobu — Thu, 12 Oct 2023 17:42:37 +0000

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.

Remote execution in the GNOME tracker

rfunk — Thu, 12 Oct 2023 17:31:47 +0000

The problem is that tracker-extract is using a *thread* model rather than a *process* model. With a process model this would not have happened, because there would not be shared memory space.

Remote execution in the GNOME tracker

ianmcc — Thu, 12 Oct 2023 17:23:54 +0000

That has its own problems if you ever need to subtract indices, or count backwards. The basic problem is the undetected overflow. If you overflow an unsigned int in a place that isn't designed to handle it, that will cause problems too.

Personally I think it would be better if the C spec said that the result of an arithmetic operation would be always correct if the value can fit in the type, and give an easy to test way to detect if it can't fit.

WUFFS

pizza — Thu, 12 Oct 2023 16:07:38 +0000

> This component should be written in WUFFS.
> 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.

WUFFS

eru — Thu, 12 Oct 2023 15:54:44 +0000

Thanks, interesting project.

WUFFS

tialaramex — Thu, 12 Oct 2023 14:38:52 +0000

> The problem is that those processes need to sandbox themselves competently, otherwise you get this.

No. There is no need for this to be written in a general purpose programming language and then try to "sandbox" it. This component should be written in WUFFS. Because WUFFS isn't a general purpose language, it's not necessary that functions such as "If the right bytes are provided as input, execute arbitrary code to escape from a sandbox" can be written even on purpose, let alone by accident.

In WUFFS: A buffer overflow won't compile. Not "Oh we add runtime bounds checks for you", it just says nah, this code might have a bounds miss so you can't do that. You can write your own bounds check and, if it's correct, that'll work, most likely you'll write "fast" code that doesn't need bounds checks, and, again, if it's correct that'll work too.

WUFFS is focused on mechanically proving that whatever you've written is safe. Is it correct? Don't care. But it's safe. Maybe you write some WUFFS to turn JPEGs into 16x16 thumbnail images. Does it produce orange blocks for an input of a grassy landscape even thought that's clearly wrong? WUFFS doesn't care. But what it won't do is oops, I just executed the sixth lines of pixels as raw machine code on your computer.

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.

https://github.com/google/wuffs

Remote execution in the GNOME tracker

tshow — Thu, 12 Oct 2023 14:36:17 +0000

Surely one of the lessons here (admittedly amongst several...) is "don't use signed integers for array indices unless you actually have a legitimate use for negative values". I think we'd have been better off if the C spec had said `int` was unsigned, and you had to explicitly request `signed int`.

Remote execution in the GNOME tracker

josh — Thu, 12 Oct 2023 13:55:48 +0000

If all you need is computation and an input and output pipe, that's quite easy with wasmtime.

If you need to expose a variety of API functions to the WebAssembly layer, that's straightforward as well, but a little more challenging, though it's about to get a lot easier with the new component model that just got standardized.

Remote execution in the GNOME tracker

grawity — Thu, 12 Oct 2023 12:14:08 +0000

In a sense, that's what tracker-extract already was – it's a worker process that gets a job queue via IPC from tracker-miner (the crawler) and stores results via IPC in tracker proper (the database).

The problem is that those processes need to sandbox themselves competently, otherwise you get this.

Remote execution in the GNOME tracker

SLi — Thu, 12 Oct 2023 09:44:56 +0000

I'd think harder guarantees could, in theory, be provided for C.

Actually, how hard would it be to make integrating C and C-on-WebAssembly smoother?

Imagine you could just write code that looks something like this:

struct output {
    int something;
    bool ok;
};

// WASM_OUT: wasm may write here
// WASM_STRZ: input for WebAssembly, size determined by strlen()

[[webassembly]] int sensitive_computation([[wasm_out]] struct output *out, const char *str, struct something smth) {
    ...
}

void foo(int x, const char *str, struct something smth) {
    struct output out;
    int x = sensitive_computation(WASM_OUT(out), WASM_STRZ(str), smth);
    ...
}

The call would spawn a WebAssembly environment, copy str's bytes to its memory address, and after the execution has finished would copy the contents of out to foo's struct out and return the value returned by the function. I'd expect to be use completely normal C in sensitive_computation, apart from of course anything that requires system calls or memory management. We might perhaps add another function type, [[webassembly_internal]], which is a function that can be called from WebAssembly code without restrictions (i.e. it's not limited to the in/out thing, it is linked into the same WebAssembly binary and operates in the same sandbox).

But I must say I do not quite know how much scaffolding and setup WebAssembly requires.

Remote execution in the GNOME tracker

jengelh — Thu, 12 Oct 2023 09:24:48 +0000

>Finding ways to work in memory-safe replacements

There is a somewhat low-hanging fruit here: Write programs with a process model in mind, e.g. like Postfix has employed it successfully for over 20 years. X and Wayland are essentially also process-based environments with IPC going on between a compositor and a program that paints into a buffer.

Remote execution in the GNOME tracker

roc — Wed, 11 Oct 2023 21:36:22 +0000

"While not perfectly airtight" is a joke. If you told any security professional, or just anyone who knows anything about sandboxing, that you were running a fully privileged thread doing complicated work in the same address space as your "sandboxed" threads, they would simply laugh at you and point out that hijacking that privileged thread is going to be easy. It's "not perfectly airtight" in the same way that a butterfly net is not perfectly airtight.