https://web.archive.org/web/20210116101222/https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/ Wayback Machine success fail [https://www.jwz.org/][Go] Dec JAN Feb 2 captures Previous capture 16 Next capture 16 Jan 2021 - 16 Jan 2021 2020 2021 2022 About this capture COLLECTED BY Collection: Live Web Proxy Crawls Content crawled via the Wayback Machine Live Proxy mostly by the Save Page Now feature on web.archive.org. Liveweb proxy is a component of Internet Archive's wayback machine project. The liveweb proxy captures the content of a web page in real time, archives it into a ARC or WARC file and returns the ARC/WARC record back to the wayback machine to process. The recorded ARC/WARC file becomes part of the wayback machine in due course of time. TIMESTAMPS loading * Home * About Me * About This Blog * DNA Lounge * Patreon * Search for: [ ] << Billboard Stealing Your Private YouTube Videos, One Frame at a Time >> I told you so, 2021 edition 10 hours ago Cinnamon-screensaver got popped, again. If you are not running XScreenSaver on Linux, then it is safe to assume that your screen does not lock. The latest: * 2021: Mash keys on the virtual keyboard to unlock Cinnamon-screensaver. Previously: * CVE-2019-3010, Privilege escalation in Oracle Solaris screen saver fork. * CVE-2014-1949, MDVSA-2015:162: Press Menu key then ESC in Cinnamon-screensaver, get shell. * Hold down keys, unlock Cinnamon-screensaver. * Hold enter, unlock Gnome-screensaver. You will recall that in 2004, which is now seventeen years ago, I wrote a document explaining why I made the design trade-offs that I did in XScreenSaver, and in that document I predicted this exact bug as my example of, "this is what will happen if you don't do it this way." And they went and made that happen. Repeatedly. Every time this bug is re-introduced, someone pipes up and says something like, "So what, it was a bug, they've fixed it." That's really missing the point. The point is not that such a bug existed, but that such a bug was even possible. The real bug here is that the design of the system even permits this class of bug. It is unconscionable that someone designing a critical piece of security infrastructure would design the system in such a way that it does not fail safe. Especially when I have given them nearly 30 years of prior art demonstrating how to do it right, and a two-decades-old document clearly explaining What Not To Do that coincidentally used this very bug as its illustrative strawman! These bugs are a shameful embarrassment of design -- as opposed to merely bad code. This same bug keeps cropping up in these other screen lockers for several reasons. 1. Writing security-critical code is hard. Most people can't do it. 2. Locking and authentication is an OS-level problem. And while X11 is at the heart of the OS of a Linux desktop computer, it was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. That makes the problem even harder. 3. This mistake of the X11 architecture can never, ever be fixed. X11 is too old, too ossified, and has too many quagmire-trapped stakeholders to ever make any meaningful changes to it again. That's why people keep trying to replace X11 -- and failing, because it's too entrenched. As always, these bugs are terrible because bad security is worse than no security. If you knew for a fact that your screen didn't lock, you would behave appropriately. Maybe you'd log out when you walked away. Maybe you wouldn't use that computer for certain things. But a security placebo makes you behave as if it's secure when in fact it is not. One of the infuriating parts of these recurring bugs is that the screen-locker part of XScreenSaver isn't even the fun part! I do not enjoy working on it. I never have. I added it in response to demand and necessity, not because it sounded like a good time. I started and continue this project as an outlet for making art. I'd much rather be spending my time pushing triangles. Sigh. And in not-at-all-unrelated news: Just to add insult to injury, it has recently come to my attention that not only are Gnome-screensaver, Mint-screensaver and Cinnamon-screensaver buggy and insecure dumpster fires, but they are also in violation of my license and infringing my copyright. XScreenSaver was released under the BSD license, one of the oldest and most permissive of the free software licenses. It turns out, the Gnome-screensaver authors copied large parts of XScreenSaver into their program, removed the BSD license and slapped a GPL license on my code instead -- and also removed my name. Rude. If they had asked me, "can you dual-license this code", I might have said yes. If they had asked, "can we strip your name off and credit your work as (C) William Jon McCann instead"... probably not. Mint-screensaver and Cinnamon-screensaver, being forks and descendants of Gnome-screensaver, have inherited this license violation and continue to perpetuate it. Every Linux distro is shipping this copyright- and license-infringing code. I eagerly await hearing how they're going to make this right. Previously, previously, previously, previously, previously. Tags: computers, copyright, doomed, firstperson, linux, security, xscreensaver << Billboard Stealing Your Private YouTube Videos, One Frame at a Time >> 8 Responses: 1. [1e7] different Jamie says: 10 hours ago at 7:25 pm A copyright letter to Big [S:Red:S]Blue could be entertaining. Or on the other hand, not. Reply + [b2e] Misty Jean says: 9 hours ago at 8:09 pm Yes, I'm sure the Nazgu'l will find it very entertaining Reply 2. [32d] Zygo says: 9 hours ago at 8:13 pm There's an update in Ubuntu 20.04 (Mint 20.x) which backports xorg 1.20.9 towards focal... that backport actually messed up and missed the CVE fix (which is present in the groovy version), so upgrading to this temporarily fixes this issue. When Ubuntu realize this mistake they'll backport the CVE fix again and this will break again. I am familiar with this process! If upstream releases a regression and then a fix in the next point release, there will be Ubuntu, releasing the same regression some weeks after both the regression and fix are known. Then the package maintainer takes a vacation so the fix finally lands on user machines months later. Reply 3. [05a] Sean says: 4 hours ago at 1:10 am I enjoy that the commit message removing you from AUTHORS says 'not much left of that'. Not 'there is none of this code left that is under a different license', just 'not much', so we're cool, right? Even if there was none of your code left (and ignoring the license violation), it would still be polite to at least mention that it was based on XScreenSaver originally. Reply 4. [904] k says: 2 hours ago at 2:35 am Thanks you allmighty jwz, I am jumping out of joy same as you (really, hillariuos) and swear an oath to use only xscreensaver ever. Reply 5. [616] x64k says: 1 hour ago at 3:51 am The bug ticket, if you haven't read it, is very much "2021 Linux in a nutshell", too. You'd think this bug was found after a security audit or something. A brainstorming session, then someone looked at the source code looking for bugs. Or maybe some cyberpunk neo-noir hacker sat at his keyboard for 42 hours straight looking at green letters on a black background until he found the dreaded NULL pointer and he attained enlightenment by staring into its void. Nope: > A few weeks ago, my kids wanted to hack my linux desktop, so they typed and clicked everywhere, while I was standing behind them looking at them play... when the screensaver core dumped and they actually hacked their way in! wow, those little hackers... Reply 6. [c05] Soni says: 29 minutes ago at 5:03 am uh so like what about using something like lunatic to run the toolkit in-process with fail-safe guarantees? is that something to look into or would it be a waste of time? .-. (really want to do it tho) Reply 7. [2b4] tfb says: 4 minutes ago at 5:28 am The 'this class of bug should not be possible' argument is great. But it's a cause that was lost before most people working on Linux were born. The class of bug which is 'buffer overflows' (which, I bet, is what is underlying the bugs here) can be (almost entirely) prevented by language design. Such languages have existed almost since there were high-level languages. Yet because it was hard to make them fast and small enough to be really usable on a PDP-11 fifty years ago we all live with buffer overflows, except now we live with buffer overflows in systems vast beyond comprehension. And we all know this and still we pretend there is hope. Reply Leave a Reply Cancel reply Your email address will not be published. But if you provide a fake email address, I will likely assume that you are a troll, and not publish your comment. Name * [ ] Email * [ ] Website [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment [ ] You may use these HTML tags and attributes: