1
I Use This!
Activity Not Available

News

Analyzed almost 2 years ago. based on code collected almost 2 years ago.
Posted 10 days ago by t...@mirbsd.org (MirOS Developer tg)
Giacomo Tesio referenced mksh(1) in his annual Jehanne report and provided a guest post (dated 2018-01-09, sorry for posting it this late only) for us on his journey on porting mksh to Jehanne, his Plan 9 derivative operating system. Read on for his story! (read more…)
Posted 3 months ago by t...@mirbsd.org (MirOS Developer tg)
I’m in Bruxelles again, as every year since 2001, for FOSDEM. (I only missed OSDEM in 2000, mostly due to the curse of late birth.) To revive a tradition, I’ve attempted (and successfully at that!) to find a place where we can eat Couscous ... [More] Merguez, and we met up with bsiegert@ and had some nice conversation and, besides the overly LOUD!!! belly dance, delicious food. It was nice to catch up with each other again. Other than that, see you over the next few days at ULB! Don’t miss the MuseScore booth and the two Teckids talks. Colophon: complexity sucks. [Less]
Posted 4 months ago by t...@mirbsd.org (MirOS Developer tg)
I’ve been going to FOSDEM for about half of my lifetime, give or take a year I think. So, of course, I will be there again this year. Thanks to my employer for sponsoring travel and accommodation again. It’s a bit annoying that the future of ... [More] alternative OSes is a bit misty right now, depending on the hardware, but we’re continuing development, in subprojects (like mksh(1) and jupp(1), for example) and other projects (like Debian and MuseScore, whom I’ll meet at FOSDEM again) while researching possible fixes for the security theatre. [Less]
Posted 4 months ago
The unveiling of the three new CPU bug classes, collected in the two brandbugs “Meltdown” and “Spectre”, has mostly shocked the BSDs; I’ve got it on some authority that even FreeBSD was not informed ahead of time, left alone the others. Thanks to ... [More] laffer1 from MidnightBSD for a couple of heads-up warnings into our direction! Here’s what I could gather until now (please do correct me if I’m wrong): Meltdown is specific to Intel® CPUs with out-of-order execution, that is, all P6-class (Pentium Pro/MMX, Pentium Ⅱ, but not Pentium Ⅰ/MMX) or newer (except old Atom) CPUs. It appears to allow user processes to read kernel memory, but not across VMs, nor to attack a hypervisor. A variant for ARM exists but AMD’s x86 CPUs are supposedly safe. The KAISER/FUCKWIT/UASS/KPTI patches for Linux fix this, at huge performance cost on x86, not so much on ARM, and no cost for unaffected CPU models (runtime detected). Spectre affects x86, ARM, POWER CPUs and possibly others. I’ve not yet found information on whether it is also limited to CPUs with out-of-order executions, but it seems likely. SPARC CPUs might be safe; Solaris/SPARC64 is safe due to the way its memory addressing works. If the OOO execution assumption is true, 80486 and P5 class x86 CPUs are also safe. This one does allow cross-VM and hypervisor attacks, so if the bare metal CPU is vulnerable, SOL. There does not yet seem to be a generic fix; some hint at having to patch the compiler and recompile everything with a workaround that has a performance cost, even if the CPU is not affected, or was fixed with a microcode update. AMD’s x86 CPUs are partially hit, one of the variants does not work on them. “CERT recommends throwing away your CPU and buying an non-vulnerable one” (thanks to El Reg), but nobody states which CPUs are not vulnerable. At the present time, we suggest any MirBSD/i386 instances that run on any CPU other than an 80486 or P5-class (Pentium Ⅰ or a non-PPro MMX) to be restricted to single user or trusted user access only, and no untrusted software including ECMAscript to be run on them. Watch this space for updates. Oh, and, if you know what you’re (and I’m) talking about, please, again, do provide me with information necessary to provide those updates, both to MirBSD and to this space. Thank you. [Less]
Posted 4 months ago by t...@mirbsd.org (MirOS Developer tg)
MirBSD on the Sun
Posted 4 months ago by t...@mirbsd.org (MirOS Developer tg)
MirBSD on the Sun
Posted 8 months ago by t...@mirbsd.org (MirOS Developer tg)
I’ll not respond, much, until next Monday. We have FrOSCon.
Posted 8 months ago by t...@mirbsd.org (MirOS Developer tg)
I’ll not respond, much, until next Monday. We have FrOSCon.
Posted 9 months ago by t...@mirbsd.org (MirOS Developer tg)
Considering I’ve become the de-facto upstream of cvs(GNU) even if not yet formally the de-iure upstream maintainer, fixing this bug obviously falls to me — not quite the way I had planned passing this evening after coming home from work and a ... [More] decent and, worse, very filling meal at the local Croatian restaurant. But, so’s life. The problem here is basically that CVS invokes ssh(1) (well, rsh originally…) but doesn’t add the argument separator “--” before the (user-provided) hostname, which when starting with a hyphen-minus will be interpreted by ssh as an argument. (Apparently the other VCSes also had additional vulnerabilities such as not properly escaping semicoloi or pipes from the shell or unescaping percent-escaped fun characters, but that doesn’t affect us.) The obvious fix and the one I implemented first is to simply add the dashes. This will also be backported to Debian {,{,old}old}stable-security. Then I looked at other VCSes out of which only one did this, but they all added extra paranoia hostname checks (some of them passing invalid hostnames, such as those with underscores in them). OK, I thought, then also let’s add extra checks to CVS’ repository reference handling. This will end up in Debian sid and MirBSD, pending passing the regression tests of course… hah, while writing this article I had to fixup because a test failed. Anyway, it’s not strictly necessary AFAICT to fix the issue. Update, about 2⅕ hours past midnight (the testsuite runs for several hours): of course, the “sanity” testsuite (which itself is rather insane…) also needs adjustments, plus a bonus fix (for something that got broken when the recent allow-root-regex patch was merged and got fixed in the same go to…night). tl;dr: a fix will end up in Debian *stable-security and can be taken out of my mail to the bugreport; another few changes for robustness are being tested and then added to both MirBSD and Debian sid. The impact is likely small, as it’s hard to get a user (if you find one, in the first place) to use a crafted CVSROOT string, which is easy to spot as well. Update, Monday: apparently someone took care of the DSA and DLA yesterday after ACCEPTing the uploads — thanks, I was outside during the day. Update 2017-08-25: It was noted that ssh(1) does not parse its command line correctly, and therefore the patch above might not be enough in the general case. However, I still think it’s good enough for CVS because it constructs its command line in a way that doesn’t let users exploit that bug. [Less]
Posted 9 months ago by t...@mirbsd.org (MirOS Developer tg)
Considering I’ve become the de-facto upstream of cvs(GNU) even if not yet formally the de-iure upstream maintainer, fixing this bug obviously falls to me — not quite the way I had planned passing this evening after coming home from work and a ... [More] decent and, worse, very filling meal at the local Croatian restaurant. But, so’s life. The problem here is basically that CVS invokes ssh(1) (well, rsh originally…) but doesn’t add the argument separator “--” before the (user-provided) hostname, which when starting with a hyphen-minus will be interpreted by ssh as an argument. (Apparently the other VCSes also had additional vulnerabilities such as not properly escaping semicoloi or pipes from the shell or unescaping percent-escaped fun characters, but that doesn’t affect us.) The obvious fix and the one I implemented first is to simply add the dashes. This will also be backported to Debian {,{,old}old}stable-security. Then I looked at other VCSes out of which only one did this, but they all added extra paranoia hostname checks (some of them passing invalid hostnames, such as those with underscores in them). OK, I thought, then also let’s add extra checks to CVS’ repository reference handling. This will end up in Debian sid and MirBSD, pending passing the regression tests of course… hah, while writing this article I had to fixup because a test failed. Anyway, it’s not strictly necessary AFAICT to fix the issue. Update, about 2⅕ hours past midnight (the testsuite runs for several hours): of course, the “sanity” testsuite (which itself is rather insane…) also needs adjustments, plus a bonus fix (for something that got broken when the recent allow-root-regex patch was merged and got fixed in the same go to…night). tl;dr: a fix will end up in Debian *stable-security and can be taken out of my mail to the bugreport; another few changes for robustness are being tested and then added to both MirBSD and Debian sid. The impact is likely small, as it’s hard to get a user (if you find one, in the first place) to use a crafted CVSROOT string, which is easy to spot as well. Update, Monday: apparently someone took care of the DSA and DLA yesterday after ACCEPTing the uploads — thanks, I was outside during the day. Update 2017-08-25: It was noted that ssh(1) does not parse its command line correctly, and therefore the patch above might not be enough in the general case. However, I still think it’s good enough for CVS because it constructs its command line in a way that doesn’t let users exploit that bug. [Less]