Chris Evans, a Chrome security engineer at Google, writes about vulnerabilities, exploits, and reverse engineering of old floppy disks and computers.
HN commenters cite it for the Linux desktop 0day exploit, an early cookie forcing writeup, and the floppy disc recovery post. They note he works on Chrome security.
First, it's fascinating to watch newcomers discovering obsolete tech that was so current when I got into computers. I recall 8", 5.25" and 3.5" floppies very well. Most of this 'rediscovered' tech I'm already familiar with (it makes me feel like a dinosaur).
I recall aligning Shugardt SA800 8" floppy drives with an oscilloscope and it's described in the maintenance manuals along with the circuit diagrams—yes, there was actually a time when we automatically had the Right to Repair and manufacturers provided circuit diagrams and repair information as an accepted and normal practice (back in the 1980s the very notion of Right to Repair would have been foreign and ridiculous to us)!
(Incidentally, I still own two SA800 drives, they're still mounted side-by-side in their docking bay. I also have copies of the operation and maintenance manuals. They not only cover the theory of operation of the drive but also its maintenance and alignment procedures.)
As the linked article demonstrates (https://scarybeastsecurity.blogspot.com/2021/05/recovering-lost-treasure-filled-floppy.html?m=1), when one cannot read a floppy or gets data errors during a read the first thing to do is to try different drives as the read sensitivity and mechanical alignment can vary from drive to drive—even if one's drive is in perfect mechanical alignment the disk one is trying to read may have been recorded on a drive that was out of alignment (tiny alignment differences don't matter much in normal operation…
I asked that question myself before[1], and others, too [2].
But the answer is a clear no. Read this explanation [3] on oss-security where someone lays out in detail in which ways ASAN creates security problems.
It ultimately is just not built as a protection mechansim, but as a debugging tool. While you'd catch some bugs (UAFs, Buffer overreads), you introduce others.
Maybe there could be a "like asan but designed for production" tool. I think Softbound-CETS was trying to go in that direction, but never became production ready and is as far as I know no longer developed. But right now such a tool does not exist.
Though however what absolutely should be done: Every C/C++-written tool should be tested with ASAN. This doesn't happen (not a single Linux distro uses ASAN testing as a default practice before adding packages), and this is very sad. (I know this because I still find major packages that have ASAN-findable bugs exposed by their own test suite.)
[1] https://blog.hboeck.de/archives/879-Safer-use-of-C-code-running-Gentoo-with-Address-Sanitizer.html
[2] https://scarybeastsecurity.blogspot.com/2014/09/using-asan-as-protection.html
[3] https://www.openwall.com/lists/oss-security/2016/02/17/9
> You have not been paying attention. Maybe consider accepting the advice of experts?
It would be great to have a few of these issues sourced in the comment (and your comments on the Tor Browser expanded with some reasoning) just so everyone is on the same page. I've seen some exploits with Tor Browser but I thought they'd be mostly sorted out.
I get that Chrome has some more mature sandboxing code, but I must admit I'm not a fan of how it handles a lot of things including download behaviour (http://security.stackexchange.com/q/145808 and https://scarybeastsecurity.blogspot.co.uk/2016/11/0day-poc-risky-design-decisions-in.html), Firefox at least does a better job here.
I agree with the advice for border passage, only thing that makes this difficult is the state of upload speeds.
>By default, there are no services listening.
Desktop linux, not "the Linux kernel". The kernel isn't amazing, but on the desktop side you regularly see downright absurd stuff like this
https://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html
and less surprising bugs like this https://donncha.is/2016/12/compromising-ubuntu-desktop/
The quality of software outside of some widely deployed server software tends to be quite poor, exploit mitigations are not being implemented.
>And what malware runs on Linux?
Far too many to list. You can easily find hundreds of public examples. This terrible wikipedia page provides a decent starting point with a list of names to google https://en.wikipedia.org/wiki/Linux_malware
This is why you have never seen FTPS in the wild, from the vsftpd.conf manual page:
ssl_enable
If enabled, and vsftpd was compiled against OpenSSL, vsftpd will
support secure connections via SSL. This applies to the control
connection (including login) and also data connections. You'll
need a client with SSL support too. NOTE!! Beware enabling this
option. Only enable it if you need it. vsftpd can make no guar‐
antees about the security of the OpenSSL libraries. By enabling
this option, you are declaring that you trust the security of
your installed OpenSSL library.
Default: NO
https://scarybeastsecurity.blogspot.com/2015/07/vsftpd-303-released-and-horrors-of-ftp.html
There are interpreters for programs that are delivered over the network to be run locally by the unsuspecting user, in some surprising places.
For example: Here's a sound player that contains an entire 6502-based virtual machine, because the "sound file format" that it "plays" is actually an executable program. Unfortunately, the virtual machine hardware is not properly simulated, allowing the 6502 code to memory-map parts of the virtual machine manager itself using the virtual memory controller hardware and alter them.
* http://scarybeastsecurity.blogspot.co.uk/2016/11/0day-exploit-compromising-linux-desktop.html (https://news.ycombinator.com/item?id=12951503)