A remote code execution vulnerability in GNOME [LWN.net]

The GitHub blog describes a vulnerability in the libcue library (which is used by the GNOME desktop) that can be exploited by a remote attacker to run code on a desktop system if the target can be convinced to click on a malicious link.

The video shows me clicking a link in a webpage, which causes a cue sheet to be downloaded. Because the file is saved to ~/Downloads, it is then automatically scanned by tracker-miners. And because it has a .cue filename extension, tracker-miners uses libcue to parse the file. The file exploits the vulnerability in libcue to gain code execution and pop a calculator.

to post comments

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 14:19 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (28 responses)

Cue sheet - now that's something I haven't heard in a very long time.

Letting parsers for a gazillion obscure formats loose on random untrusted inputs, without any user action, is a questionable idea IMHO. Doing that in an environment that isn't locked down to death, so that the most any exploit could do is generate a bogus thumbnail, is more than questionable I'd say.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 14:34 UTC (Tue) by madscientist (subscriber, #16861) [Link] (7 responses)

According to the comments at the end of the linked article, the parser IS run in a sandbox. Unfortunately there was an issue with that (unpublished as of yet) that was since fixed as well (according to the article).

So, yes, locked down. No, not locked down to death, apparently.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 15:13 UTC (Tue) by leromarinvit (subscriber, #56850) [Link]

I was about to reply to myself, after noticing that in the article. But that just goes to show that tightly sandboxing arbitrary code that wasn't specifically designed with that in mind is hard, and sometimes impossible.

I'm still not convinced the idea of automatically running parsers that evidently weren't designed to run in a completely locked down environment (if they were, the sandbox could be much tighter: e.g. only read and write on already open fds, and maybe brk with a low enough memory limit set via cgroups) on untrusted data is a good one.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:16 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

> According to the comments at the end of the linked article, the parser IS run in a sandbox. Unfortunately there was an issue with that (unpublished as of yet) that was since fixed as well (according to the article).

Details of the sandbox changes itself is covered in https://blogs.gnome.org/carlosg/2023/10/10/on-cve-2023-43...

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 0:52 UTC (Wed) by roc (subscriber, #30627) [Link] (4 responses)

Having the main thread be fully privileged and running in the *same address space* as "sandboxed" threads is ridiculous and does not deserve to be called a sandbox at all.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 13:10 UTC (Wed) by fredrik (subscriber, #232) [Link] (3 responses)

Right, we should not blame seccomp for the failure to confine this vulnerability in tracker-miner.

I'm no C programmer, but would a better solution in this case be to use posix_spawn to start a separate process which solely reads the file being indexed and returned text. With the assumption that a separate spawned executable could be locked down stricter with seccomp than a forked thread in the same process namespace?

Still, the problem with the argument that seccomp only failed in this case because tracker-miner used it wrong, is that it is an argument of purity, like no true Scotsman...

On the other hand: OpenSSH also uses seccomp, and is implemented in C, and handles untrusted user input in a privileged environment. So, apparently for some true Scotsmen, like the OpenSSH developers, it seems to be possible to not fail to implement secure software in the C programming language. Though, that might be the exception which proves the rule?

The author of both the current fix and the previous implementation of seccomp in tracker-miners confirms (AFAIU) that the seccomp sandbox in tracker-miner was and is a compromise. Many of the libraries tracker-miner use to extract text from files were not designed with confinement and seccomp in mind. So it seems that tracker-miner had to lower the guards to get any useful output at all. Still, when that compromise was on the table, a better option would have been to abandon that aproach and find another more appropriate way forward. One that didn't compromise security for sake of features.

BTW, tracker-miner still use Gstreamer to parse files, despite Gstreamer being a known source of security issues. Reported by LWN already in 2016.
https://lwn.net/Articles/708196/

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 15:56 UTC (Wed) by NYKevin (subscriber, #129325) [Link]

> On the other hand: OpenSSH also uses seccomp, and is implemented in C, and handles untrusted user input in a privileged environment. So, apparently for some true Scotsmen, like the OpenSSH developers, it seems to be possible to not fail to implement secure software in the C programming language. Though, that might be the exception which proves the rule?

This is a poor example, because SSH has a functional requirement to offer remote access to an authenticated/authorized user. If you sandbox it to death, then it can't do its job, so you have no choice but to take a more permissive approach. On the other hand, the vast majority of software has no such functional requirement, and therefore can be sandboxed much more aggressively than SSH servers.

Remember: There's really no such thing as absolute security. There's "harder to hack" and "easier to hack." Sandboxing is, ideally, a defense-in-depth measure. Software should be designed to avoid failing or misbehaving on malicious inputs, regardless of whether a sandbox is present, but no software is perfect, so we sandbox things to further mitigate the risk.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 10:54 UTC (Thu) by gfernandes (subscriber, #119910) [Link] (1 responses)

The OP did not blame seccomp.

The OP made a very valid point - running a thread in a sandbox, in the same process/address space where rhe main thread is NOT sandboxed, invalidates the sandbox.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 13:52 UTC (Thu) by mcatanzaro (subscriber, #93033) [Link]

Indeed, that's the best TL;DR here.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 15:32 UTC (Tue) by fredrik (subscriber, #232) [Link] (19 responses)

It is notable that the target of this vulnerability, the file indexer tracker-miner, apparently had employed both ASLR and seccomp sandboxing in an attempt to prevent exploits.

That reminds me of the Chromium Rule of 2. Only in this case there was a sandbox, but the unsafe language still allowed untrustworthy inputs to compromise the system. Oh well, at least it was a mistake no real C programmer worth his salt would ever make, surely?

Granted, the project was started in 2005 when safer languages weren't such a hot topic as today, but can we at least stop and take notice now: The use of memory-unsafe languages are no longer appropriate when dealing with unsafe input! If at all.

</rant>

https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/rule-of-2.md

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:13 UTC (Tue) by rweikusat2 (subscriber, #117920) [Link] (17 responses)

The vulnerability is an integer overflow, ie, someone using atoi(3) to parse a number and assuming the result will always be positive. This an ancient UNIX interface which has been deficient (or unexpectedly featured) since its invention in the early 1970s (it's already documented as machine code subroutine for the first version of UNIX). The proper way to handle this is to use the proper interface for it (strtoul(3) --- standardized since the first ANSI C standard) and check for error returns.

I don't think the attitude behind this kind of "Just can't be arsed!"-coding can be fixed by doing it in a different programming language.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:36 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

> I don't think the attitude behind this kind of "Just can't be arsed!"-coding can be fixed by doing it in a different programming language.

It may very well help. Languages like say Go or Rust have less legacy traps but also are typically used with optional linters like gosec and Clippy that warns about the common issues. I don't know whether C developers are usually doing this.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 20:57 UTC (Tue) by Wol (subscriber, #4433) [Link]

Well, when I set the coding standards for C programming, the rule was simple.

"I know we can't stop the compiler complaining, but you set the warning level to max and if you can't explain the warning away, it's a fatal error".

That was Microsoft C, and with warning level set to 4, we were calling a bought-in library and we couldn't suppress the "unused argument" warning. Anything else got fixed.

Cheers,
Wol

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 21:02 UTC (Tue) by proski (guest, #104) [Link] (1 responses)

I worked on C++ code in the past where we were making a great effort to catch possible issues in the code (~90% unit test coverage, code sanitizers, Valgrind, using multiple compilers with all warnings enabled), but I'm not sure we would catch that error unless testing the problematic value. With Rust, on the other hand, I'm confident that a non-exploitable panic is the worst thing we could get even without clippy.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 8:58 UTC (Wed) by NAR (subscriber, #1313) [Link]

The presence of atoi in itself is a code smell - and has been for the past 20 years.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 21:00 UTC (Tue) by dvrabel (guest, #9500) [Link] (11 responses)

    fn main() {
        let i = "4294903295".parse::<u32>().unwrap() as i32;
        let v = vec![1, 2];
        if i >= (v.len() as i32) {
            return;
        }
        /* SAFETY: Bounds already checked. */
        let a = unsafe {
            v.get_unchecked(i as usize)
        };
        println!("{} {}", i, a);
    }

This is broadly what the vulnerability is, implemented in rust. This segfaults and can presumably result in similar exploits in real code.

It took a bit more work and the unsafe block should make reviewers look more carefully but the comment and the (similarly incorrect) bounds check could easily lead the reviewer to conclude its ok, particularly if this was buried in a larger commit and was being reviewed on a Friday afternoon.

Rust is a better language, but does not negate the need for through unit, component, system, and fuzz testing.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 22:26 UTC (Tue) by walters (subscriber, #7396) [Link] (3 responses)

In Rust it's much more idiomatic to use iterators (as well as the checked `get()`) than direct array indexing because in many case it's actually *more* ergonomic, and doing so helps the compiler elide bounds checks actually.

For example https://doc.rust-lang.org/std/primitive.slice.html#method... is just way better than doing the equivalent indexing by hand.

So usage of `get_unchecked` is IME very unusual in Rust and would be a large code smell outside of very low level code.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 23:49 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

The `as` casts are also very non-idiomatic. I think as a translation it *works*, but yes, it's not what a "native" Rust programmer would write. Rather, someone that knows C, learned Rust-the-language but not Rust-with-its-stdlib.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 17:51 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

I'm not even sure a person who knows C-but-not-Rust would put in those casts. I find it hard to believe that the average C programmer would choose to parse something into a u32 and then immediately cast it to an i32 - that just makes no logical sense at all. If you want a u32, you parse it into a u32. If you want an i32, you parse it into an i32.

OTOH, the second cast (v.len() as i32) looks like it's implementing the "usual integer promotions" rule from C (i.e. the rule that everything magically promotes to int if you so much as breathe on it), and the last one (i as usize) is pretty transparently "the compiler made me do it." But C programs do int promotion because it is implicit, not because C programmers consciously choose to promote everything to int. Would a C programmer really choose to write code that juggles three different types, if all of the casts have to be written out explicitly? I'm not very good with Rust, but even I would see that and think "there has to be a better way" - and in this case, it seems fairly obvious that you can just parse it as usize to begin with. Then all of the casts go away and the bug is also fixed.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 19:52 UTC (Wed) by ballombe (subscriber, #9523) [Link]

Compile your C code with g++ and suddenly you get warning for unsigned/signed mismatch.
That is what I do, and I only ever write C code.

This vulnerability is less about the C language than about the ISO C committee mental block about allowing explicit semantic qualifier for C type.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 0:55 UTC (Wed) by roc (subscriber, #30627) [Link] (4 responses)

No-one would write this Rust code unless they were malicious, it's totally unnatural.

If you're reviewing file parsing code and you see "unsafe", that's a huge red flag. Come back to it on Monday.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 13:18 UTC (Wed) by smoogen (subscriber, #97) [Link] (3 responses)

I could see it coded this way without 'direct' malicious intent:
1. It is a 'from another language' coder tasked with Rust code but not 'familiar' with what is Natural in Rust but familiar with their own language.
2. They are under a deadline and have been trying to deal with a time/speed issue in some code. They find this method is 'not natural' but faster. [Many sins in other languages occur because of this.]
3. They got this from some AI assist which found that comment and assumed it was good code.
4. They got this from reddit/etc where someone with direct malicious intent put it up in either a 'joke'(*) or to make something bad happen.

All of the items are poor coding in one way or another but not directly malicious.

(*) A long time ago I wrote a man page for a program which set real memory (rm) flag on files. This was to allow you to avoid getting swapped out in virtual memory on any file it was given. An additional bonus was to set the real fast flag on files so that the were set to nice -10 and get all the CPU. As a 'joke' it was sort of funny. When it was taken seriously... it was not.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 13:37 UTC (Wed) by Wol (subscriber, #4433) [Link]

Hmmm...

Many moons ago on a multi-user system, I set up a batch queue. Back in the day when an 800MB winchester drive was about 5" x 5" x 2' in size. Any jobs submitted to that queue were basically set to max cpu priority, max i/o priority. However, it didn't get used much because it was also set to max 30sec wall clock. Beyond that, any job got terminated with prejudice. It was, however, useful for getting little jobs done quick :-)

Cheers,
Wol

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 18:03 UTC (Wed) by mb (subscriber, #50428) [Link]

>1. It is a 'from another language' coder tasked with Rust code but not 'familiar' with what is Natural in Rust but familiar with their own language.

Well, such a person would probably never use 'unsafe' and probably also wouldn't use 'get_unchecked'. The person would probably just do 'v[i]'. Which is safe.

This code is totally not what happens in the real world.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 21:29 UTC (Wed) by roc (subscriber, #30627) [Link]

Those things theoretically could happen in but in practice they don't.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 14:07 UTC (Wed) by farnz (subscriber, #17727) [Link]

As a Rust reviewer, I pick on the following issues; let's assume that I don't spot the vulnerability, but that I throw this code back to you with the following comments. Can you rework to address my review comments, without making the bug more obvious?

I see three casts using "as"; these are dangerous because they don't do checks as part of the cast. Can you rewrite these using from, into, try_from or try_into?
The Rust compiler is great at optimizing out bounds checks in most situations; can you use get, instead of get_unchecked, and rely on the optimizer removing the bounds check? If not, why not?

Basically, you've got two things in there (get_unchecked, and as casting) which trigger my "this is likely to be buggy" radar. Add in "unsafe", which triggers my "this needs close inspection" radar, and I'm likely to spot that there is an issue when I try to get you to write better Rust.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 9:04 UTC (Thu) by Tobu (subscriber, #24111) [Link]

I don't believe someone would write this innocently when the alternative is a simple v[s.parse::<usize>()?].

I looked at the cue-parsing crates I could find: cuna, rbchunk, rcue, cue_sheet, none of them use unsafe, rcue forbids unsafe_code. cuna does depend on parser library nom, which has uses of unsafe in six string splitting functions and has unsafe dependencies for memchr and float parsing.

I do wish clippy had a blanket lint against all uses of `as` for numeric casts, which are a code smell when from/try_from exist. Right now you have to go through this list, many of which are allowed by default, and there are holes.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 18:38 UTC (Wed) by adobriyan (subscriber, #30858) [Link]

strtoul() doesn't force to check for error. Programmer who is clueless to use atoi() will write strtoul() just as easily.
And there is no strtouint() so potential for clipping the result is still there.

A remote code execution vulnerability in GNOME

Posted Oct 11, 2023 0:53 UTC (Wed) by roc (subscriber, #30627) [Link]

It wasn't a proper sandbox at all, see my comment above.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 15:29 UTC (Tue) by tjeb (guest, #127466) [Link] (1 responses)

Just tested it out on a Debian Bookworm system, and I do see the crash so it's likely to be vulnerable too. I've added '*.cue' to /org/freedesktop/tracker/miner/files/ignored-files in dconf-editor as a temporary mitigation.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 17:16 UTC (Tue) by Tobu (subscriber, #24111) [Link]

My incantation is:

printf '[Desktop Entry]\nType=Application\nHidden=true\n' > ~/.config/autostart/tracker-miner-fs-3.desktop
systemctl --user mask --now tracker-miner-fs-3.service

There is also a gsettings key (gsettings get org.freedesktop.Tracker3.Miner.Files ignored-files) but I don't know that the cue parser would only come up for this extension.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 16:56 UTC (Tue) by sjj (guest, #2020) [Link]

Sandbox or not, automatically opening and parsing files in obsolete formats in ~/Downloads is a fine example the idiotic hubris of 20th c. programming.

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 18:18 UTC (Tue) by walters (subscriber, #7396) [Link] (1 responses)

"cue the rewrite it in Rust comments" ;)

A remote code execution vulnerability in GNOME

Posted Oct 10, 2023 18:42 UTC (Tue) by amacater (subscriber, #790) [Link]

Surely "NOT .cue the rewrite in Rust" is what you meant?

So why not simply uninstall it?

Posted Oct 10, 2023 20:11 UTC (Tue) by mikebenden (guest, #74702) [Link] (8 responses)

E.g., on Fedora: rpm -e --nodeps tracker tracker-miners

Yeah, gnome-session (via nautilus) and gnome-photos or whatever will "miss" it, but other than that, why would I *not* just nuke it from orbit? :)

So why not simply uninstall it?

Posted Oct 10, 2023 23:58 UTC (Tue) by jreiser (subscriber, #11027) [Link] (4 responses)

In Fedora Linux (and thus perhaps RHEL), the 'locate' utililty (search an updated-in-advance list of filenames present on the system) was removed in favor of tracker stuff. That's a loss for me.

So why not simply uninstall it?

Posted Oct 11, 2023 4:59 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (3 responses)

No it wasn't! It was even updated from `mlocate` to `plocate` recently.
I have plocate-1.1.17-3.fc39.x86_64 installed on this very computer.

Replacement for locate on Fedora?

Posted Oct 11, 2023 12:11 UTC (Wed) by fredrik (subscriber, #232) [Link] (2 responses)

I was just about to suggest to jreiser to install the package plocate instead.

https://plocate.sesse.net/
https://packages.fedoraproject.org/pkgs/plocate/plocate/

Though, plocate is implemented in C++, so it too seems to use a memory-unsafe language to parse unsafe user input.

Replacement for locate on Fedora?

Posted Oct 11, 2023 15:50 UTC (Wed) by hmh (subscriber, #3838) [Link] (1 responses)

"locate" and friends (plocate, slocate, etc) do not parse files, they don't even open them. They just fstat() them, if that much.

The typical security issue with locate, is that one user could find out the existence of files owned by some other user, supposedly addressed by slocate, and hopefully by plocate (didn't check).

Replacement for locate on Fedora?

Posted Oct 12, 2023 6:51 UTC (Thu) by Sesse (subscriber, #53779) [Link]

plocate makes pretty much the same set of security checks as mlocate, indeed, which is that the calling user should be able to find the file from / (i.e., it verifies that you can access() with +rx the entire containing path up from the root).

It does not try to protect the user against itself, i.e., being safe against untrusted .db files (and it takes pains to drop setgid before actually starting to parse the files, so that you cannot run an attack on a secret .db file using your own malicious one).

(I am the author of plocate.)

So why not simply uninstall it?

Posted Oct 11, 2023 15:24 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

Yeah. I run XFCE4 on Debian, and there were only a couple of packages that depended on it. They weren't packages I'd miss, so I did the old apt --purge remove libcue2

So why not simply uninstall it?

Posted Oct 11, 2023 16:35 UTC (Wed) by ballombe (subscriber, #9523) [Link] (1 responses)

You should rather remove tracker-miners.

So why not simply uninstall it?

Posted Oct 12, 2023 2:10 UTC (Thu) by dskoll (subscriber, #1630) [Link]

That was removed as part of the uninstallation. But the flaw is in the libcue2 library and there were other programs (audacious) that depended on it.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 3:21 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (5 responses)

Ah, so that's it, gnome finally managed to emulate windows so well that it even implemented the support for the long-known trivial attacks consisting in remotely launching whatever utility based on just a file name extension ? Then probably the next steps will be to run a program under wine when it's called "index.exe.html" (or .htm , sorry). Users are often presented as an excuse to do whatever in their back "because they're too dumb to make a choice, you see", but I will never resolve to this, it's only in this state because such systems make a business of not instructing users and keeping them ignorant of what really matters such as what application to use to open a file.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 4:06 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (4 responses)

That's not an accurate description of what happened here. Tracker indexes files in order to make it easy for users to search for them. That means it has to parse them in order to extract the relevant data for indexing. This has nothing to do with whether users are considered to be too ignorant to make reasonable choices.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 6:10 UTC (Thu) by Wol (subscriber, #4433) [Link] (3 responses)

The problem here - baloo and friends cough cough - is half the time the user has no clue what the indexer does, and the other half of the time the user has no use for the indexer's output!!!

You'd have thought they'd have learnt from the KDE4 debacle rendering large numbers of computers "unbootable". 36 hours and counting for getting to desktop from the login screen isn't a big enough hint?

Cheers,
Wol

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 7:33 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

I have both an idea of what it does and a need for it. But why should someone need to understand software to benefit from it? I have a poor understanding of what a DOM is, but I'm still happily using a browser. Should indexers be both poorly sandboxed and written in unsafe languages? No. Does that mean they shouldn't exist? Also no.

A remote code execution vulnerability in GNOME

Posted Oct 12, 2023 11:46 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

No I'm not asking that a user should understand software that they are using.

I'm saying "please don't hand the user a chainsaw - UNASKED FOR - when they never cut wood".

I think KDE was unusable on my system for maybe six months, before someone said "put -semantic-desktop in your make.conf" and bingo! Things worked again!

My current system, I use xosview and it tells me I have four cores ... (I think that is four unthreaded cores). When I log in, cpu load typically hits 10, 14, for maybe 5 mins, and the system is horribly unresponsive. I really ought to put -semantic-desktop back in to make.conf. And when I asked what semantic-desktop did, I was told "oh, it makes kmail run faster". A program I don't use - I use TB.

I don't care whether indexers are sandboxed. I don't care whether they are written in safe or unsafe languages. I don't care whether they exist or not. But I DO care when they eat my CPU cycles, waste my time, endanger my computer, and they're so badly documented it takes me six months to find out that they're the problem I'm trying to track down!!! Plus the benefits I get in return aren't worth the electrons they're written with!

Cheers,
Wol

A remote code execution vulnerability in GNOME

Posted Oct 13, 2023 10:30 UTC (Fri) by sandeep_89 (guest, #127524) [Link]

Yes I had the same problem. Kept drainingy laptop battery, heating up the laptop and slowing it down. I masked and disabled the damn thing. Same for baloo, Windows Search Indexer.

Useless badly written plagues that act like our one computer is Google or the NSA wanting to index everything.

A remote code execution vulnerability in GNOME

Posted Oct 13, 2023 10:02 UTC (Fri) by sandeep_89 (guest, #127524) [Link]

I disabled tracker-miner long ago because it was doing unnecessary background work and draining my laptop battery.

This kind of scanning should be once a day at best.

A remote code execution vulnerability in GNOME

Posted Oct 16, 2023 21:05 UTC (Mon) by bartoc (guest, #124262) [Link] (1 responses)

It seems like an easy mitigation here would be for tracker to just not do any of this scanning on stuff that has the "mark of the web". Obviously this doesn't totally solve the problem because it's pretty easy for the MOTW to be accidentally removed, but at least it would require more than just downloading a file.

A remote code execution vulnerability in GNOME

Posted Oct 16, 2023 23:46 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Not that I use GNOME either, but `curl` downloads far more files than Firefox on my machine. AFAIK, it doesn't do any of the xattr stuff to mark things as "tainted".