ugjka 2 weeks ago • 100%
I lost my watch in snow in forest once. Had to use one of those finder apps, centimeter level accuracy would have saved 2 hours
ugjka 2 weeks ago • 80%
For desktop you can get headphones with a wireless dongle that doesn't have to adhere to Bluetooth limitations and in fact most of them also have Bluetooth for phone use
ugjka 2 weeks ago • 86%
AFAIK it would only be a war crime if this was sprayed on civilians
ugjka 2 months ago • 100%
Hetzner 5 buckaroos a month 22TB a month
ugjka 3 months ago • 100%
I tried it and deleted it on first day, it just felt like the same Facebook but for instagram users, same shit with everything being determined with algo feeds
ugjka 3 months ago • 97%
I realized long time ago that I don't want my 2FA be tied to my phone number. And then i found you can't export your data from Authy because they know they are scummy fucks and don't want to anyone to leave
ugjka 3 months ago • 85%
I hate Elon, but he ain't the only one trashing the LEO
ugjka 3 months ago • 100%
Enjoy your skincancer
ugjka 5 months ago • 33%
ugjka 5 months ago • 80%
ugjka 5 months ago • 100%
ugjka 5 months ago • 100%
I recently got the diphtheria and tetanus vax booster which you need every 10 years, i think i was 2 years late on this one because like most people after high school i had forgotten or simply do not care. Took some digging to find my childhood vax passport. This only came to my mind after i had done my 3rd covid booster
ugjka 5 months ago • 100%
Oh is see it is the porn site itself blocking the uk visitors, not the uk govt doing fancy blocking. Why people keep posting paywalled shit, i can't read
ugjka 5 months ago • 50%
ugjka 5 months ago • 100%
Is this actual IP ban at ISP level or just the usual dns blocking that can be bypassed with cloudflare dns or something similar
ugjka 5 months ago • 96%
ugjka 5 months ago • 50%
ugjka 5 months ago • 100%
Hetzner if you are in the EU, dirt cheap haven't had a problem. Had to use customer support once, wasn't a problem either.
ugjka 5 months ago • 100%
OBS screencap https://ugjka.net/video/gab.ai.mp4
ugjka 6 months ago • 76%
AI? You meant 1000 people in India, perhaps
ugjka 6 months ago • 100%
I use webcord, hopefully they'll integrate an adblocker
ugjka 6 months ago • 100%
updated my post, it was just some speculation i misread
ugjka 6 months ago • 33%
there will be federal investigation just speculation if the culprit is a foreign actor
ugjka 6 months ago • 95%
Somewhat related... I have aliased yt-dlp with "yt-dlp -4" because my IPv4 address is behind CGNAT which they can't rate limit without disrupting legit users. When running with IPv6 I always get rate limited or even blocked
ugjka 7 months ago • 100%
Hollywood accounting tactics probably aswell
ugjka 8 months ago • 100%
let's cancel all history and restart afresh
ugjka 8 months ago • 100%
Use something like Mullvad for everything so that ip adresses don't matter
ugjka 8 months ago • 100%
He actally streamed it live on twitter periscope
ugjka 8 months ago • 100%
I don't know why they made it that way, but you have to jump start the battery from the service port before anything can happen
ugjka 8 months ago • 33%
The problem is that charging does not work on Telsas if the battery is completely dead, you can't even open the doors
ugjka 8 months ago • 66%
It is fun for a while but for most people the novelty wears off quickly and a vr headset just sits mostly unused in some cabinet. Wearing this kind of thing on your head is just annoying
ugjka 8 months ago • 100%
It happened when they shut down google labs back in 00's. Geeks got kicked out and it was all in on money
ugjka 8 months ago • 50%
This is dead tech, they're only pushing it because it is 10 years of billions in R&D and a lot of egos involved
ugjka 8 months ago • 100%
ugjka 8 months ago • 100%
Most likely brand new lines have that functionality but 90% of grid is very old
ugjka 8 months ago • 100%
I only have it for groups, the only place on Facebook where meaningful interaction is still possible
ugjka 8 months ago • 100%
smells like money laundering, no one in the right mind would pay that much
ugjka 8 months ago • 100%
11$/mo, they are not fucking around
ugjka 8 months ago • 100%
Also less chance to get long covid if you boost yearly
ugjka 8 months ago • 100%
Err, isn't it just mostly criminals doing various criminal schemes using NFTs as a tool?
cross-posted from: https://lemmy.world/post/7123900 > Date: Tue, 17 Oct 2023 03:17:36 +0300 > From: turistu > To: oss-security@...ts.openwall.com > Subject: with firefox on X11, any page can pastejack you anytime > > Note to the moderator: I have already submitted this to the firefox people > three weeks ago, and according to them, this is not a real security issue, > or at least not worse than those pesky scripts which you cannot kill without > killing firefox itself; if you think the same, just ignore this without > replying. > > I would however appreciate if you let this through and so give it some > visibility so that the other 2 or 3 people who may be affected by this > could learn about it. > > Thank you very much. > > ==== > > In firefox running on X11, any script from any page can freely write to the > primary selection, and that can be easily exploited to run arbitrary code > on the user's machine. > > No user interaction is necessary -- any page able to run javascript can do it, > including e.g. a page from a background tab of a minimized window, an iframe > inside such a window, an error page, a sandboxed iframe, a page that has > reloaded itself via `meta http-equiv=refresh`, etc. > > This applies to all the versions of mozilla/firefox and their derivatives > (seamonkey, etc) that I was able to test, including the latest nightly. > > ### Example > > The simplest example, which works in the default configurations of systems > like OpenBSD or Alpine Linux (= any Unix/Linux system where Wayland is not > the default and the default *shell* does not implement bracketed-paste), > would go like this: > > Load the following snippet in firefox: > > <pre></pre> > intentionally left blank > > > Then pretend to forget about it, and go about your work. Sooner or later, > when trying to paste something in the terminal with shift-Insert or middle > click, you will end up running the command `writeXPrimary()` has injected > just between your copy and paste. > > live example of that snippet: https://turistu.github.io/firefox/pastejack.html > > ### Short technical explanation > > Browsers like firefox have the concepts of "secure context" (e.g. `https://`) > and "transient user activation"; the javascript from the page gets some > temporary powers as soon as you have interacted *even so little* with the > page, like clicked, touched, etc. > > For instance, writing with `Clipboard.writeText()` to the windows-style > Ctrl-C Ctrl-V *clipboard* selection is only possible from secure contexts > and only in the short while after the user has clicked a button, etc on the page. > As this bug demonstrates, those prerequisites are not needed for writing to the > *primary* selection, which on X11 is much more used and much more valuable. > > ### Workaround > > Without patching firefox, the only workaround I can think about is > disabling the `Clipboard.selectAllChildren()` function from an addon's > content script, e.g. like this: > > let block = function(){ throw Error('blocked') }; > exportFunction(block, Selection.prototype, { defineAs: 'selectAllChildren' }); > > Complete extension here at https://github.com/turistu/odds-n-ends/raw/main/firefox/no-sel.xpi. > > I tried to submit it to addons.mozilla.org but they didn't accept it. If > you're running firefox-esr, the development edition or nightly, you can just > `set xpinstall.signatures.required` to true in `about:config` and install > it with `firefox no-sel.xpi`. > > ### Firefox Patch > ``` > diff -r 9b362770f30b layout/generic/nsFrameSelection.cpp > --- a/layout/generic/nsFrameSelection.cpp Fri Oct 06 12:03:17 2023 +0000 > +++ b/layout/generic/nsFrameSelection.cpp Sun Oct 08 11:04:41 2023 +0300 > @@ -3345,6 +3345,10 @@ > return; // Don't care if we are still dragging. > } > > + if (aReason & nsISelectionListener::JS_REASON) { > + return; > + } > + > if (!aDocument || aSelection.IsCollapsed()) { > #ifdef DEBUG_CLIPBOARD > fprintf(stderr, "CLIPBOARD: no selection/collapsed selection\n"); > ``` > > The idea of this patch was to *always* prevent javascript from indirectly > messing with the primary selection via the Selection API. However, it turned > out that the `JS_REASON` flag was not reliable; if javascript calls some > function like `addRange()` or `selectAllChildren()` while the user has started > dragging but hasn't released the mouse button yet, that code will be called > *without* that flag but with the text set by javascript, not the text > selected by the user. However, I think that this patch is still enough > to fill the glaring hole opened by `selectAllChildren()`. > > ### About the example and bracketed-paste > > The bracketed paste feature of bash/readline and zsh means that you > cannot just append a CR or LF to the payload and be done, it's the > user who has to press ENTER for it to run. > > However, workarounds exist. For instance, some terminals like mlterm > don't filter out the pasted data, and you can terminate the pasting > mode early by inserting a `\e[201~` in the payload. > > For bash, you can take advantage of some quirks in the readline library > to turn off the highlighting and make the payload invisible to the user. > E.g.: > > let payload = 'touch ~/LOL-' + Date.now() / 1000; > writeXPrimary('\n' + payload + '\n'.repeat(100) + ' '.repeat(30) > + '\n'.repeat(100)) > > which will confuse the user with the same screen as when some stray background job > had written something to the terminal: > > user@...t:~$ : previous unrelated command > user@...t:~$ <-- paste here > # <-- cursor here, most users will just hit Enter to get a new prompt > > live example of that snippet: https://turistu.github.io/firefox/bash-pastejack.html > > Just to be clear, I don't think that either mlterm, bash, nor the shells that > don't do have that bracketed-paste feature are at fault here in any way > (and I personally always turn off that misfeature as it badly interferes > with my workflow): It's firefox which should get all the blame for letting > random javascript evade its pretended "sandbox" in this way. > > ### About Wayland > > For firefox running in Wayland, `writeXPrimary()` will only succeed > when the firefox window (the main window, not necessarily the tab the code > runs in) has the focus. Otherwise the selection will be cleared. At first I > assumed that this is something specific to the Wayland protocol, but that > turned out to be utterly false; it's just some quirk, bug or "feature" > specific to either firefox itself or GTK. > > But I think that's still bad enough, even if the page should take care to > only set the selection when the main window has gained focus. > > And of course, all this doesn't affect the situation where you're copying > and pasting in another firefox tab with a different context, origin, etc; > and all the other situations where you don't appreciate having random > javascript you don't even know about messing with your copy & paste. > > === > > This is a slightly edited version of > https://github.com/turistu/odds-n-ends/blob/main/firefox/pastejack.md. > > I will correct any errors or omissions and also add more info there.
Date: Tue, 17 Oct 2023 03:17:36 +0300 From: turistu To: oss-security@...ts.openwall.com Subject: with firefox on X11, any page can pastejack you anytime Note to the moderator: I have already submitted this to the firefox people three weeks ago, and according to them, this is not a real security issue, or at least not worse than those pesky scripts which you cannot kill without killing firefox itself; if you think the same, just ignore this without replying. I would however appreciate if you let this through and so give it some visibility so that the other 2 or 3 people who may be affected by this could learn about it. Thank you very much. ==== In firefox running on X11, any script from any page can freely write to the primary selection, and that can be easily exploited to run arbitrary code on the user's machine. No user interaction is necessary -- any page able to run javascript can do it, including e.g. a page from a background tab of a minimized window, an iframe inside such a window, an error page, a sandboxed iframe, a page that has reloaded itself via `meta http-equiv=refresh`, etc. This applies to all the versions of mozilla/firefox and their derivatives (seamonkey, etc) that I was able to test, including the latest nightly. ### Example The simplest example, which works in the default configurations of systems like OpenBSD or Alpine Linux (= any Unix/Linux system where Wayland is not the default and the default *shell* does not implement bracketed-paste), would go like this: Load the following snippet in firefox: <pre></pre> intentionally left blank Then pretend to forget about it, and go about your work. Sooner or later, when trying to paste something in the terminal with shift-Insert or middle click, you will end up running the command `writeXPrimary()` has injected just between your copy and paste. live example of that snippet: https://turistu.github.io/firefox/pastejack.html ### Short technical explanation Browsers like firefox have the concepts of "secure context" (e.g. `https://`) and "transient user activation"; the javascript from the page gets some temporary powers as soon as you have interacted *even so little* with the page, like clicked, touched, etc. For instance, writing with `Clipboard.writeText()` to the windows-style Ctrl-C Ctrl-V *clipboard* selection is only possible from secure contexts and only in the short while after the user has clicked a button, etc on the page. As this bug demonstrates, those prerequisites are not needed for writing to the *primary* selection, which on X11 is much more used and much more valuable. ### Workaround Without patching firefox, the only workaround I can think about is disabling the `Clipboard.selectAllChildren()` function from an addon's content script, e.g. like this: let block = function(){ throw Error('blocked') }; exportFunction(block, Selection.prototype, { defineAs: 'selectAllChildren' }); Complete extension here at https://github.com/turistu/odds-n-ends/raw/main/firefox/no-sel.xpi. I tried to submit it to addons.mozilla.org but they didn't accept it. If you're running firefox-esr, the development edition or nightly, you can just `set xpinstall.signatures.required` to true in `about:config` and install it with `firefox no-sel.xpi`. ### Firefox Patch ``` diff -r 9b362770f30b layout/generic/nsFrameSelection.cpp --- a/layout/generic/nsFrameSelection.cpp Fri Oct 06 12:03:17 2023 +0000 +++ b/layout/generic/nsFrameSelection.cpp Sun Oct 08 11:04:41 2023 +0300 @@ -3345,6 +3345,10 @@ return; // Don't care if we are still dragging. } + if (aReason & nsISelectionListener::JS_REASON) { + return; + } + if (!aDocument || aSelection.IsCollapsed()) { #ifdef DEBUG_CLIPBOARD fprintf(stderr, "CLIPBOARD: no selection/collapsed selection\n"); ``` The idea of this patch was to *always* prevent javascript from indirectly messing with the primary selection via the Selection API. However, it turned out that the `JS_REASON` flag was not reliable; if javascript calls some function like `addRange()` or `selectAllChildren()` while the user has started dragging but hasn't released the mouse button yet, that code will be called *without* that flag but with the text set by javascript, not the text selected by the user. However, I think that this patch is still enough to fill the glaring hole opened by `selectAllChildren()`. ### About the example and bracketed-paste The bracketed paste feature of bash/readline and zsh means that you cannot just append a CR or LF to the payload and be done, it's the user who has to press ENTER for it to run. However, workarounds exist. For instance, some terminals like mlterm don't filter out the pasted data, and you can terminate the pasting mode early by inserting a `\e[201~` in the payload. For bash, you can take advantage of some quirks in the readline library to turn off the highlighting and make the payload invisible to the user. E.g.: let payload = 'touch ~/LOL-' + Date.now() / 1000; writeXPrimary('\n' + payload + '\n'.repeat(100) + ' '.repeat(30) + '\n'.repeat(100)) which will confuse the user with the same screen as when some stray background job had written something to the terminal: user@...t:~$ : previous unrelated command user@...t:~$ <-- paste here # <-- cursor here, most users will just hit Enter to get a new prompt live example of that snippet: https://turistu.github.io/firefox/bash-pastejack.html Just to be clear, I don't think that either mlterm, bash, nor the shells that don't do have that bracketed-paste feature are at fault here in any way (and I personally always turn off that misfeature as it badly interferes with my workflow): It's firefox which should get all the blame for letting random javascript evade its pretended "sandbox" in this way. ### About Wayland For firefox running in Wayland, `writeXPrimary()` will only succeed when the firefox window (the main window, not necessarily the tab the code runs in) has the focus. Otherwise the selection will be cleared. At first I assumed that this is something specific to the Wayland protocol, but that turned out to be utterly false; it's just some quirk, bug or "feature" specific to either firefox itself or GTK. But I think that's still bad enough, even if the page should take care to only set the selection when the main window has gained focus. And of course, all this doesn't affect the situation where you're copying and pasting in another firefox tab with a different context, origin, etc; and all the other situations where you don't appreciate having random javascript you don't even know about messing with your copy & paste. === This is a slightly edited version of https://github.com/turistu/odds-n-ends/blob/main/firefox/pastejack.md. I will correct any errors or omissions and also add more info there.
Firefox and Fastly take another step toward a privacy upgrade for the internet Fastly and Mozilla are taking another important step toward a more secure and private internet with Firefox’s adoption of Fastly as an Oblivious HTTP (OHTTP) Relay in order to guarantee more privacy for Firefox users. We are thrilled to work in partnership with Firefox and Mozilla, who have a proven track record of investing in technologies that protect their users and working to improve the internet. How does Oblivious HTTP (OHTTP) work? OHTTP is a spec and service architecture that engineers can use to enable more private communications between two parties by splitting the information about the requester from the information of the request being made. You can read more about OHTTP here, but the basic idea is that it is “double-blind” in the sense that the spec is designed so that there is never a single party who has all of the information about who is making a request, and what the request is. When OHTTP is not in use all of that data is mixed together, which leaves room for abuse or misuse, and also means that a malicious attack could gain access to that data. With OHTTP a new level of privacy is guaranteed. firefox blog image 2 Fastly serves as the OHTTP Relay, receiving a request from the OHTTP client (in this case it would be in the browser), that includes metadata about the requester which Fastly can read and strip away, as well as an encapsulated and encrypted request that is passed along through the relay as designed. Fastly never knows what information is in the request itself, and Mozilla never knows any of the metadata about the requester. Browsers are the beginning The double blind communication enabled by a new generation of private-by-design technologies are impossible with HTTP alone. We believe that OHTTP, MASQUE*, and DAP** represent the beginning of a more private and secure future for all communications on the internet. Browsers occupy an important position, sitting between users and a great deal of their activity on the internet. When Firefox and other browsers adopt new technologies like this it sends an important signal that this level of privacy-by-design should be table-stakes going forward. Working toward a more private internet This technology is still relatively complicated to implement, being adopted by larger organizations like the most popular browsers, but we are getting a glimpse of a future where more is possible. We have seen this before with the adoption of HTTPS, which is now expected and the default – not just for business and large organizations, but even for small personal websites. Fastly views the work to bring OHTTP and other privacy protecting technologies to browsers and apps as a fundamental, necessary first step. Connected/smart device manufacturers, network hardware companies, and the consumer electronics industry at large are becoming more serious about compliance and privacy. And with the help of organizations like Mozilla, we are laying the groundwork for a future where applications – even smaller ones without the resources of an Apple, Google, Microsoft, or Mozilla, will be able to access OHTTP simply. We won’t arrive at this state tomorrow, but we are starting to have options for how to get there. Our goal is to create a future where all internet communications are private through the democratization of these private-by-design technologies. We must start with specific use cases and particular protocols with organizations like Mozilla who share this vision, and are ready to be early adopters. Over time the aim is to broaden the use of the technology as the private communication pathways are more universally available and easy to use. We expect this to be pushed forward in at least a couple ways – first, by continued regulatory moves and privacy legislation that forces adoption of these kinds of technologies. Second, we expect it to evolve to be a standard that users expect, like the lock in their URL bar for HTTPS connections. This is the commoditization of privacy in a great way, where improved privacy becomes cheap to the point that it is only a negligible cost to adopt an improved standard, and a reputational cost if you don’t adopt it. Fastly will not be the only option for providing a relay for this type of feature, but we do intend to be the best option. We intend to be the change we want to see in the internet and move all of us toward a future of complete privacy in internet traffic. *MASQUE = Multiplexed Application Substrate over QUIC Encryption **DAP = Distributed Aggregation Protocol (for privacy preserving measurement)
Today, in coordination with Ilya Lipnitskiy (the maintainer of libcue) and the distros mailing list, the GitHub Security Lab is disclosing CVE-2023-43641, a memory corruption vulnerability in libcue. We have also sent a text-only version of this blog post to the oss-security list. It’s quite likely that you have never heard of libcue before, and are wondering why it’s important. This situation is neatly illustrated by xkcd 2347: libcue is a library used for parsing cue sheets—a metadata format for describing the layout of the tracks on a CD. Cue sheets are often used in combination with the FLAC audio file format, which means that libcue is a dependency of some audio players, such as Audacious. But the reason why I decided to audit libcue for security vulnerabilities is that it’s used by tracker-miners: an application that’s included with GNOME—the default graphical desktop environment of many open source operating systems.1 The purpose of tracker-miners is to index the files in your home directory to make them easily searchable. For example, the index is used by this search bar: The index is automatically updated when you add or modify a file in certain subdirectories of your home directory, in particular including ~/Downloads. To make a long story short, that means that inadvertently clicking a malicious link is all it takes for an attacker to exploit CVE-2023-43641 and get code execution on your computer: The video shows me clicking a link in a webpage2, 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. Cue sheets are just one of many file formats supported by tracker-miners. For example, it also includes scanners for HTML, JPEG, and PDF. I am delaying publication of the proof of concept (PoC) used in the video, to give users time to install the patch. But if you’d like to test if your system is vulnerable, try downloading this file, which contains a much simpler version of the PoC that merely causes a (benign) crash. The offsets in the full PoC need to be tuned for different distributions. I have only done this for Ubuntu 23.04 and Fedora 38, the most recent releases of Ubuntu and Fedora at this time. In my testing, I have found that the PoC works very reliably when run on the correct distribution (and will trigger a SIGSEGV when run on the wrong distribution). I have not created PoCs for any other distributions, but I believe that all distributions that run GNOME are potentially exploitable. The bug in libcue libcue is quite a small project. It’s primarily a bison grammar for cue sheets, with a few data structures for storing the parsed data. A simple example of a cue sheet looks like this: REM GENRE "Pop, dance pop" REM DATE 1987 PERFORMER "Rick Astley" TITLE "Whenever You Need Somebody" FILE "Whenever You Need Somebody.mp3" MP3 TRACK 01 AUDIO TITLE "Never Gonna Give You Up" PERFORMER "Rick Astley" SONGWRITER "Mike Stock, Matt Aitken, Pete Waterman" INDEX 01 00:00:00 TRACK 02 AUDIO TITLE "Whenever You Need Somebody" PERFORMER "Rick Astley" SONGWRITER "Mike Stock, Matt Aitken, Pete Waterman" INDEX 01 03:35:00 The vulnerability is in the handling of the INDEX syntax. Replacing one of those INDEX statements with this will trigger the bug: INDEX 4294567296 0 There are two parts to the problem. The first is that the scanner (cue_scanner.l, line 132) uses atoi to scan the integers: [[:digit:]]+ { yylval.ival = atoi(yytext); return NUMBER; } atoi does not check for integer overflow, so it is easy to construct a negative index. For example, 4294567296 is converted to -400000 by atoi. The second part of the problem (and this is the actual vulnerability) is that track_set_index does not check that i ≥ 0: void track_set_index(Track *track, int i, long ind) { if (i > MAXINDEX) { fprintf(stderr, "too many indexes\n"); return; } track->index[i] = ind; } If i is negative, then this code can write to an address outside the bounds of the array. Since the value of ind is also attacker-controlled, this is a very powerful vulnerability. The bug is simple to fix by adding an extra condition to the if-statement in track_set_index. This is the proposed patch: diff --git a/cd.c b/cd.c index cf77a18..4bbea19 100644 --- a/cd.c +++ b/cd.c @@ -339,7 +339,7 @@ track_get_rem(const Track* track) void track_set_index(Track *track, int i, long ind) { - if (i > MAXINDEX) { + if (i < 0 || i > MAXINDEX) { fprintf(stderr, "too many indexes\n"); return; } More about tracker-miners I want to be clear that this bug is not a vulnerability in tracker-miners. But I have focused on tracker-miners because it magnifies the impact of this bug due to the way that it automatically scans the files in your ~/Downloads directory. tracker-miners consists of two processes: tracker-miner-fs tracker-extract The first, tracker-miner-fs, is a background process which is always running, whereas the second, tracker-extract, is only started on demand to scan new files. tracker-miner-fs uses inotify to monitor specific directories, such as ~/Downloads, ~/Music, and ~/Videos. When a new file is created, it launches tracker-extract to scan the file. tracker-extract sends the results back to tracker-miner-fs (which maintains the index) and then usually shuts down again after a few seconds. The vulnerability only affects tracker-extract, because that’s where libcue is used. Both processes run as the current user, so this vulnerability would need to be chained with a separate privilege escalation vulnerability for an attacker to gain admin privileges. The vulnerability will not trigger if tracker-miners is not running. To check if it is, I use the command ps aux | grep track. It usually shows that tracker-miner-fs is running and that tracker-extract isn’t. If neither is running (which I think is rare), then using the search bar (press the “super” key and type something) should automatically restart tracker-miner-fs. As far as I know, tracker-miners is quite tightly integrated into GNOME, so there’s no easy way to switch it off. There’s certainly nothing like a simple checkbox in the settings dialog. There’s some discussion here about how to switch it off by modifying your systemd configuration. The two-process architecture of tracker-miners is helpful for exploitation. Firstly, it’s much easier to predict the memory layout in a freshly started process than in one that’s already been running for hours, so the fact that tracker-extract is only started on-demand is very convenient. Even better, tracker-extract always creates a fresh thread to scan the downloaded file, and I’ve found that the heap layout in the thread’s malloc arena is very consistent: it varies between distributions, so, for example, Ubuntu 23.04 has a slightly different layout than Fedora 38, but on the same distribution the layout is identical every single time. Secondly, because tracker-extract is restarted on demand, an attacker could potentially crash it many times until their exploit succeeds. Due to the consistency of the heap layout, I’ve found that my exploit works very reliably without needing to use this, but I could imagine an attacker loading a zip file with thousands of copies of their exploit to increase their chance of success when the victim unzips the download. tracker-miners seccomp sandbox escape The difficult part of exploiting this vulnerability was finding a way to bypass ASLR. But what I didn’t realize when I started writing the PoC, is that tracker-extract also has a seccomp sandbox which is intended to prevent this kind of exploit from working. It was a nasty surprise when I thought I had all the pieces in place for a working PoC and it failed with the error message: Disallowed syscall "close_range" caught in sandbox. But I still failed to understand that I was attempting a sandbox escape here. I just thought I needed to take a different code path that didn’t use the close_range function. So I tried a different route, it worked, and I didn’t give it any more thought until the GNOME developers asked how I’d managed to escape the sandbox. It turned out that I’d discovered the escape entirely by accident: while I was working on the new route, I unwittingly made a change to the PoC that solved it. I have since discovered that I could have got the original PoC working with a one-line change. I’ll go into more detail on this in a follow-up blog post when I publish the PoC, but for now I’ll just mention that, in response to this, Carlos Garnacho has very quickly implemented some changes to strengthen the sandbox, which will prevent this exploitation path from working in the future. Conclusion Sometimes a vulnerability in a seemingly innocuous library can have a large impact. Due to the way that it’s used by tracker-miners, this vulnerability in libcue became a 1-click RCE. If you use GNOME, please update today! I’m delaying the release of the full PoC to give users time to install the update, but planning to publish a follow-up blog post soon with details of how the full PoC works. Save an unpatched VM with Ubuntu 23.04 or Fedora 38 if you’d like to test the full PoC when I release it. Notes I currently run Ubuntu 23.04 as my main OS and I love the GNOME desktop environment. ↩ The webpage in the video is https://bugs.launchpad.net/ubuntu/+source/libcue/+bug/2036595, which is where I first notified Ubuntu’s security team about this vulnerability. They suggested that I contact the distros list. ↩
>Burning Man, the festival beloved by Silicon Valley's elite, is at risk of quenched by Tropical Storm Hilary. >Nevada's Black Rock Desert, where the event takes place each year, closed its gate due to flooding caused by the rains of Tropical Storm Hilary, The San Francisco Standard reported.