The last MirBSD Korn Shell update broke update-initramfs because I accidentally introduced a regression in field splitting while fixing other bugs — sorry!

mksh R50d was just released to fix that, and a small NULL pointer dereference found by Goodbox on IRC. Thanks to my employer tarent for a bit of time to work on it.

The MirBSD Korn Shell has got a new security and maintenance release.

This release fixes one mksh(1)-specific issue when importing values from the environment. The issue has been detected by the main developer during careful code review, looking at whether the shell is affected by the recent “shellshock” bugs in GNU bash, many of which also affect AT&T ksh93. (The answer is: no, none of these bugs affects mksh.) Stephane Chanzelas kindly provided me with an in-depth look at how this can be exploited. The issue has not got a CVE identifier because it was identified as low-risk. The problem here is that the environment import filter mistakenly accepted variables named “FOO+” (for any FOO), which are, by general environ(7) syntax, distinct from “FOO”, and treated them as appending to the value of “FOO”. An attacker who already had access to the environment could so append values to parameters passed through programs (including sudo(8) or setuid) to shell scripts, including indirectly, after those programs intended to sanitise the environment, e.g. invalidating the last $PATH component. It could also be used to circumvent sudo’s environment filter which protected against the vulnerability of an unpatched GNU bash being exploited.

tl;dr: mksh not affected by any shellshock bugs, but we found a bug of our own, with low impact, which does not affect any other shell, during careful code review. Please do update to mksh R50c quickly.

The MirBSD Korn Shell has got a new bugfix release. Thought you’d want to know ☺

Both the MirBSD Korn Shell and jupp — the editor which sucks less have seen new releases today. Please test them, report all bugs, and otherwise enjoy all the bugfixes.

Other subprojects will also have new releases… once I get around doing so after hacking them…

Update 03.07.2014: New release for MirCPIO, that is, cpio(1) and pax(1) and tar(1) in a somewhat portable package.

First of all, good news, MirBSD is not vulnerable to The Heartbleed Bug due to my deliberate choice to stick to an older OpenSSL version. My inquiry (in various places) as to what precisely could leak when a vulnerable client connected to a nōn-vulnerable server has yet to be answered, though we can assume private key material is safe.

Now the bad news: while the CA I use¹ and a CA I don’t use offer free rekeying (in general), a CA I also use occasionally² refuses to do that. The ugly: they will not even revoke the certificates, so any attacker who gained your key, for example when you have been using a certificate of theirs on a Debian system, will be able to use it (e.g. to MITM your visitors traffic) unless you shell over lots of unreasonable money per certificate. (Someone wrote they got the fee waived, but others don’t, nor do I. (There’s also a great Twitter discussion-thingy about this involving Zugschlus, but I won’t link Twitter because they are not accessible to Lynx users like me and other Planet Debian authors.)

Now I’ve got a dilemma here. I’ve created a CA myself, to use with MirBSD infrastructure and things like that — X.509 certificates for my hosts (especially so I can use them for SMTP) and possibly personal friends (whose PGP key I’ve signed with maximum trust after the usual verification) but am using a StartSSL certificate for www.mirbsd.org as my GoDaddy wildcard certificate expires in a week or so (due to the aforementioned monetary issues), and I’d rather not pay for a limited certificate only supporting a single vhost. There is absolutely no issue with that certificate and key (only ever generated and used on MirBSD, only using it in Apache mod_ssl). Then, there’s this soon-to-be tax-exempt non-profit society of public utility I’m working with, whose server runs Debian, and which is affected, but has been using a StartSSL certificate for a while. Neither the society nor I can afford to pay for revocation, and we do not see any possible justification for this especially in the face of CVE-2014-0160. I expect a rekey keeping the current validity end date, and would accept a revocation even if I were unable to get a new certificate, since even were we to get a certificate for the society’s domain from someplace else, an attacker could still MITM us with the previous one from Startcom.

The problem here is: I’d really love to see (all of!) Startcom dropped from the global list of trustworthy CAs, but then I’d not know from where to get a cert for MirBSD; Globalsign is not an option because I will not limit SSL compatibility to a level needed to pass their “quality” test… possibly GoDaddy, ISTR they offer a free year to Open Source projects… no idea about one for the society… but it would solve the problem of not getting the certificates revoked. For everyone.

I am giving Startcom time until Friday after $dayjob (for me); after that, I’ll be kicking them off MirBSD’s CA bundle and will be lobbying for Debian and Mozilla to do the same.

Any other ideas of how to deal with that? I’d probably pay 5 € for a usable certificate accepted by people (including old systems, such as MSIE 5.0 on Win2k and the likes) without questioning… most of the time, I only serve public content anyway and just use SSL to make the NSA’s job more difficult (and even when not I’m not dealing with any payment information, just the occasional login protected area).

By the way, is there any way to access the information that is behind a current-day link to groups.google.com with Lynx or Pine? I can’t help but praise GMane for their NNTP interface.

ObFunfact: just when I was finished writing this wlog entry, I got a new eMail “Special offer just for you.” from GoDaddy. Sadly, no offer for a 5 € SSL certificate, just the usual 20-35% off coupon code.

I’m currently moving servers and services, and have just installed MirBSD natively on the new www-to-be, fish (part of FreeWRT’s legacy). This means that some services will be temporarily unavailable in the days (*cough*) to come. Also, we will temporarily be restricted to Legacy IP availability, losing IP connectivity until I manage to set up a tunnel at the new location. Sorry for doing this “at the last minute” but it’s an involved process. On the other hand, I did already get a new SSL certificate for www.mirbsd.org (from Startcom), and begun operating a MirBSD CA (for the forth time) for all our other X.509 needs (mostly, server-to-server SSL connections including auth’d SMTP relaying).

In true “rolling release” fashion, there is a new MirBSD snapshot for the i386 architecture available in the usual netinstall location. I removed all MirPorts binary packages for previous snapshots, since there were quite some changes (libc major bump, C++ removal, etc.) in base in the meantime. (Expect some fallout. I just realised I cancelled the Manitu server (for monetary reasons), which is blazingly fast, before I was able to finish doing a usable G++ 4.4 port…)

As previously announced, the FreeWRT Project has been archived. You can access the content at the FreeWRT Archive Site on the MirWebseite.

ObRant: DST (Sommerzeit) sucks!

Thanks to Robert Scheck, jupp — the Editor which sucks less (a WordStar™-compatible Unix editor with lots of features, including a hex editor) is currently on its way to Fedora and EPEL (RHEL/CentOS 5 and 6).

Depending on your distribution, you will have it available within one to two weeks, I’m being told.

This adds another distribution to the list; jupp has been available in Debian and its derivates (some of which may not be named) for some time (due to user request), and the webpage contains Win32 binaries (made with Cygwin, an oldish version to be compatible to Win9x).

jupp is especially useful as programmers’ editor, but also used in teaching school-aged kids the joys of IT; Natureshadow has prepared a cheat sheet, which we will internationalise and localise, then link from the jupp homepage — so stay tuned! (I guess we’ll also need a concise list of jupp features, in lieu of advertising.)

mksh-current version "R48 2013/11/17" (only this version, no others) suffer from a now-known regression which can make your MirBSD system unbootable. Please immediately either revert to an earlier version (such as a stable release) or update to "R48 2013/11/29" from AnonCVS.

This reverts the fix for “x="X 1 2"; showargs ${x#X}”, which nevertheless is a genuine bug. Contributions fixing it without introducing any such regressions welcome…

The MirOS Project is proud to announce that the NetInstall area contains a fresh snapshot of MirBSD-current for the i386 and sparc architectures. In due time, a hand-crafted Live ISO image, with some packages configured and grml-mir added, will be published here, so watch this space ;-)

As someone in IRC already mentioned, MirBSD is currently published on a “rolling release” schedule (although we’ll eventually release MirBSD #11… some day). The snapshots are intended mainly for people to use when installing, or trying out MirBSD, but also as an upgrade aid (so recompiling afterwards (to be even more up to date) is very easy) and a baseline for binary packages (although there have been few (though MuPDF is a recent noteworthy addition) MirPorts packages lately, and I somehow doubt bsiegert@ wants me to gift one of my SPARCstation boxen to him for building pkgsrc® quarterlies).

Michael Langguth and Scalaris AG asked me to publish the mksh/Win32 Beta 14 source and binary archive, and it is with joy I’m doing this.

Checksums and Hashes

• RMD160 (ports/mksh-w32-beta14.zip) = 0dc8ef6e95592bd132f701ca77c4e0a3afe46f24
• TIGER (ports/mksh-w32-beta14.zip) = 966e548f9e9c1d5b137ae3ec48e60db4a57c9a0ed15720fb
• 1181543005 517402 /MirOS/dist/mir/mksh/ports/mksh-w32-beta14.zip
• MD5 (ports/mksh-w32-beta14.zip) = b57367b0710bf76a972b493562e2b6b5

Just a few words on it (more in the README.1st file included): this is a port of The MirBSD Korn Shell R39 to the native WinAPI; it’s not quite got the full Unix feel (especially as it targets the Weihenstephan unxutils instead of a full Interix or Cygwin environment) but doesn’t need a full POSIX emulation layer either. It’s intended to replace MKS ksh and the MKS Toolkit. Source for the compatibility library is also included under The MirOS Licence; we aim at publishing it as OSI Certified Open Source Software like mksh itself. (There is a situation with dlmalloc/nedmalloc being resolved, and the icon is derived from the BSD dæmon which is a protected unregistered trademark, but we’re not Mozilla and allow distro packages to keep using it ☺) Rebasing it on a newer mksh(1) followed by (partial) integration into the main source code is a goal.

Have fun trying it out and hacking on it. It’s currently built with -DMKSH_NOPROSPECTOFWORK (so coprocesses and a few other minor things won’t work), but a SIGCHLD emulation is being worked on — but if you want to help out, I’m sure it’s welcome, just come on IRC or post on the mailing list, and I’ll forward things to Michael as needed. Reports on testing with other toolchain and OS versions are also welcome.

The MirBSD Korn Shell R45 has been released today, and R44 has been named the new stable/bugfix-only series. (That’s version 45.1, not 0.45, dear Homebrew/MacOSX packagers.)

Packagers rejoice: the -DMKSH_GCC55009 dance is no longer needed, and even the run-time check for integer division is gone. Why? Because I realised one cannot use signed integers in C, at all, and rewrote the mksh(1) arithmetics code to use unsigned integers only. Special thanks to the people from musl libc and, to some lesser amount, Natureshadow for providing me with ideas what algorithms to replace some functionality with (signed shell arithmetic is, of course, still usable, it is just emulated using unsigned C integers now).

The following entertainment…

	tg@blau:~ $ echo foo >/bar\ baz
	/bin/mksh: can't create /bar baz: Permission denied
	1|tg@blau:~ $ doch
	tg@blau:~ $ cat /bar\ baz
	foo

… was provided by Tonnerre Lombard; like Swedish, German has got a number of words that cannot be expressed in English so I feel not up to the task of explaining this to people who don’t know the German word “doch”, just rest assured it calls the last input line (be careful, this is literally a line, so don’t use backslash-newline sequences) using sudo(8).