As quickly pointed out by Rick, don’t install random software that isn’t in the official distribution archive unless you really know what you’re doing (and copy/pasting commands from a website doesn’t count). You’re just asking to be made part of a botnet.
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
In Ubuntu’s Karmic and and Debian’s Lenny, sysklogd was replaced with rsyslog. This is fine, since rsyslog will have converted your /etc/syslog.conf to /etc/rsyslog.d/50-default.conf. However, if you modified the (maddeningly strange sysklogd-specific) log file rotation in /etc/cron.daily/sysklogd or /etc/cron.weekly/sysklogd, you’ll want to review the new (sane) /etc/logrotate.d/rsyslog. (Note also that savelog uses .0 as the first rotated file extension, and logrotate uses .1.)
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
I was reminded about some TPM coding I’d done to get random bytes from the pRNG on my TPM-enabled system from Matt Domsch’s recent post. I’m not fully convinced that the pRNG of the TPM is an appropriate source of entropy, but it does pass my simple FIPS-140-2 test.
I had to find the Intel TPM docs to figure out how to enable TPM on my system. It was under “Advanced / Peripherals”. I was expecting it under “Security”, like every other BIOS I’d seen. After that:
$ sudo apt-get install trousers tpm-tools
...
$ sudo modprobe tpm_tis
$ dmesg | grep -i tpm
[676618.167313] tpm_tis 00:07: 1.2 TPM (device-id 0xFE, rev-id 70)
$ sudo service trousers start
...
$ tpm_version
TPM 1.2 Version Info:
Chip Version: 1.2.2.16
Spec Level: 2
Errata Revision: 1
TPM Vendor ID: WEC
TPM Version: 01010000
Manufacturer Info: 57454300
$ ./tpm-getrand | hexdump -C
00000000 61 07 23 ff 71 3e 25 e8 f0 d5 de a7 a3 07 21 dc |a.#.q>%.......!.|
I could run rngd with a named pipe, but it’d be nice to have a new driver that could run a command instead to get the next 20000 bits.
UPDATE: I’ve implemented this in rngd now.
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
With the vrms meme raging on Planet Ubuntu, I noticed some people still have sun-java6 installed. I’ve been using openjdk-6 since Hardy, and everything I use works fine with it (e.g. Vuze, Catan, Eclipse, FreeMind, and even Facebook’s photo uploader thing). Given the Ubuntu Tech Board’s “remove sun-java6 from the archive” Agenda item, it’s possible sun-java6 (being redundant and orphaned) would go away in Ubuntu Karmic (sun-java5 is already gone because Sun will drop support for it in October, and sun-java6 is not far behind).
I’ve heard some noises about openjdk-6 not working for people, but I haven’t actually seen any direct technical evidence of something working in one and not the other. Seeing as Jaunty’s OpenJDK was certified by Sun, it would be very interesting to find failures, as this would indicate that Sun’s certifications are missing something.
Looking for examples of failures in Google, I couldn’t find anything with obvious test-cases that failed with openjdk-6. I suspect I’m just not trying hard enough, but I’m curious what other people have run into.
Test for yourself:
sudo apt-get purge sun-java6-jdk sun-java6-jre sun-java6-bin sun-java6-plugin
sudo apt-get install openjdk-6-jdk icedtea6-plugin
(Don’t forget to restart your browser.)
© 2009 – 2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
New for Linux 2.6.31 (and Ubuntu 9.10) is the ability to throw a one-way toggle to block module loading via /proc/sys/kernel/modules_disabled:
# uname -a
Linux sec-karmic-amd64 2.6.31-4-generic #23-Ubuntu SMP Mon Jul 27 18:39:59 UTC 2009 x86_64 GNU/Linux
# lsmod | head -n3
Module Size Used by
binfmt_misc 10220 1
ppdev 8200 0
# cat /proc/sys/kernel/modules_disabled
0
# modprobe usb-storage
# lsmod | head -n3
Module Size Used by
usb_storage 65600 0
binfmt_misc 10220 1
# echo 1 > /proc/sys/kernel/modules_disabled
# rmmod usb-storage
ERROR: Removing 'usb_storage': Operation not permitted
# modprobe zlib_deflate
FATAL: Error inserting zlib_deflate (/lib/modules/2.6.31-4-generic/kernel/lib/zlib_deflate/zlib_deflate.ko): Operation not permitted
# echo 0 > /proc/sys/kernel/modules_disabled
bash: echo: write error: Invalid argument
# cat /proc/sys/kernel/modules_disabled
1
The intent is for this to allow paranoid server admins (or other people not expecting to hot-plug new hardware or kernel services) the ability to block module loading without compiling a monolithic kernel.
This kind of thing used to be available through the “lcap” utility modifying the global capability bounding set (which was removed in 2.6.25), but init could always be made to turn it back on.
Combined with the removal of /dev/kmem and the hardening of /dev/mem, this closes another kernel rootkit door. It’s not a cure-all, but it’s another layer.
Now we just have to figure out ways to stamp out unexpected ioport-triggered DMA access.
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Dapper has reached it’s half-way support age. This means that only shipped server packages are getting official support. If you’re still running Dapper, upgrade to Hardy (and then consider upgrading through Intrepid to Jaunty too, since Intrepid and newer has awesome compiler defaults).
Looking back through my build logs, I can see that my desktop spent 51 hours, 48 minutes, and 37 seconds building 389 security updates. As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.
Current combined devel/security build standings per release:
hardy: 172:23:11
intrepid: 85:34:53
jaunty: 20:11:53
Thank you Dapper Desktop! I am reminded what you look like each time I start a Dapper VM. If not for that, my memory of you would have diminished long ago.
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
(In reading my prior EOL posts, I realize I should have said “Enough Edgy” or something like that to be appropriately alliterative.)
Gutsy is now officially at end-of-life.
Looking back through my build logs, I can see that my desktop spent 25 hours, 6 minutes, and 47 seconds building 208 security updates. (And 18 hours, 23 minutes, 45 seconds doing 335 builds during the Gutsy devel window.) As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.
Current combined devel/security build standings per release:
dapper: 51:27:29
hardy: 171:21:40
intrepid: 84:23:19
jaunty: 18:43:09
Thank you Gutsy! You were much nicer than Feisty, especially for wifi on my poor laptop.
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
I’m pleased to hear than the CODEGATE 2009 International Hacking Contest ran Ubuntu Intrepid for both the qualifying rounds and the final match. The host machine was running the 32bit -server kernel, so NX was active (along with all the other memory-corruption protections). From what I can see the compiled challenges were stack-protected and fortified, so the contestants had to work around that as well as the randomized stack, heap, and library locations. Sounds like it was a fun contest in a real-world situation. All that’s left now is for 64bit to become the standard. And PIE too. I can’t wait to hear more. :)
$ nm cracktris | grep _chk
U __fprintf_chk@@GLIBC_2.3.4
U __printf_chk@@GLIBC_2.3.4
U __sprintf_chk@@GLIBC_2.3.4
U __stack_chk_fail@@GLIBC_2.4
U __strcat_chk@@GLIBC_2.3.4
U __strcpy_chk@@GLIBC_2.3.4
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
I spent a while this morning hunting down the root cause of a 100% CPU MIMEDefang process. (Turned out to be one specific email triggering one of my custom SpamAssassin rules that seems to get processed really inefficiently.) I wasn’t able to find any documentation on how to debug where in MIMEDefang an email was getting stuck, and even jacking up the debugging output of my mimedefang-filter script seemed to imply it was happening late in the filtering process. After digging through mimedefang.pl, I found a “status reporting” subsystem and tracked it back out into configuration in /etc/default/mimedefang:
# Uncomment next line to have busy slaves send status updates to the
# multiplexor. NOTE: Consumes one extra file descriptor per slave, plus
# a bit of CPU time.
# MX_STATUS_UPDATES=yes
Turning this on, and then using “md-mx-ctrl busyslaves” (I command I didn’t know existed until today either) I got to see exactly where it was stuck:
3 B 13380 (Running SpamAssassin j951iX1t025805)
Now I’m having fun running md-mx-ctl with histo, barstatus, and load. :)
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
After upgrading an Ubuntu mail server from Hardy to Intrepid, two users could no longer connect via SSL to send email though sendmail. One was using msmtp and the other was using Outlook Express. The msmtp issue was tracked down as a supposed deficiency in msmtp. However, this left Outlook, which is neigh-impossible to debug. From the Debian msmtp bug linked from the Ubuntu bug, it seemed that the root cause was the server sending too much data during the initial connection. Packet captures of an Outlook connection seemed to back this up: Outlook negotiated STARTTLS fine, and then just never responded to the SSL handshake.
It seems that something (openssl? sendmail?) changed between Hardy and Intrepid so that instead of using the /etc/ssl/certs/ca-certificates.crt file just for verification, its contents were now being sent during the SSL handshake. (I reduced the number of configured certs with “sudo dpkg-reconfigure ca-certificates“, and checked on the size of the handshake with “openssl s_client -connect server:port | wc -l“.) It spewed 143 certs sent at every connection. Unsurprisingly, it seems some clients were choking on it (I would like to note that Thunderbird behaved correctly).
In the end, I configured my sendmail’s CAfile (“confCACERT”) to aim at just a single CA (the CA used to sign the server’s SSL key), and that fixed both msmtp and Outlook. How fun.
© 2009 – 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Welcome to 2009! Really, seriously, everyone can stop using MD5 now. However, be sure not to overreact. The forged CA research is a great read, but there’s no need to break existing certs. For a calm reaction, please read this.
© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Care of Mike Owens and Dustin Kirkland, bogosec has been uploaded to Jaunty (in the NEW queue at the moment). It is a source-code analyzer framework with plugins for lintian, rats, and flawfinder. Out of curiousity, I ran it on all of Intrepid main. Highest 5 scores were:
As Dustin reminded me, bogosec seems biased against smaller code bases. In the case of the lang packs, the score is entirely from lintian. Both lsscsi and powertop deal mostly with input from kernel strings, so while they scored highly, I doubt either is actually vulnerable to very much. I haven’t looked at nevow yet. Also, both rats and flawfinder yell about things that are mitigated by compiler flags (e.g. -D_FORTIFY_SOURCE=2) so those warnings are less interesting too.
Really, this all boils down to “we need better code analyzers”. The best tool will be one that predicts CVE counts (I would expect the Linux kernel to be at the top, since it has the all-time highest number of CVEs filed against it).
To get closer to reality, I think just doing a normal package build and scanning for stderr output would be meaningful (gcc has plenty of built-in checks already). Steve Beattie suggested writing a plugin for sparse, too.
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
There’s this great CPU feature called “nx” — it protects your computer from intrusion by blocking execution of memory regions that weren’t expected to be executable (i.e. stack/heap data). You really want this enabled. Unfortunately for you, it seems some BIOSes default to disabling it. On Dell laptops, look under “Security” / “CPU XD Support”: you want it enabled. In an American Megatrends BIOS, I found it under “CPU Features” / “Execute Disable Bit”: you want it enabled.
As far as making use of the CPU feature once it’s not disabled in the BIOS, you’re already using it if you’re running a 64bit kernel. And if you’re using 32bit, you can start using it if you install the -server flavor of the 32bit kernel. As a bonus, you get to address all your physical RAM if you do this too (since -server’s “PAE” mode is the kernel mode that allows “nx” to work). For Ubuntu Jaunty, I’m hoping to get some element of the system (installer? jockey?) to make the right kernel selection for a given system.
If “pae” is in your /proc/cpuinfo flags:
$ grep --color pae /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov \ pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc \ arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm
(note the “nx” in there too, since my BIOS isn’t set to disable it)
Then you almost certainly want to use -server kernel flavor:
sudo apt-get install linux-server linux-restricted-modules-server
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
If I made one of those work-site signs that tracked “Days since last incident”, and made one for “Days since last in-the-wild remote-root worm” for Windows and Linux, what would they each say? 0 and 7304 respectively?
Update: while the post was tongue-in-cheek (everyone suffers when any large subset of computers is being attacked), I should lower the Linux days count to 2783 (for L10n on March 23, 2001, which is slightly newer than Ramen on January 17, 2001). Thanks for everyone’s comments. :)
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
SSH’s new “VisualHostKey” option (in Ubuntu Intrepid and Debian Lenny) is great fun. Normally it is disabled, but it seems that “ssh-keygen” turns it on when generating new keys. In celebration of the Ubuntu release, here is a script to entertain yourself with RSA ASCII-art, care of SSH and your system’s entropy pool:
#!/bin/sh
set -e
DIR=$(mktemp -t -d rsa-art-XXXXXX)
trap "rm -f $DIR/key*; rmdir $DIR" EXIT HUP INT QUIT TERM
while :
do
ART=$(ssh-keygen -t rsa -f $DIR/key -N "" | tail -n 11)
rm -f $DIR/key
/bin/echo -e "\x1Bc"
echo "$ART"
done
Makes me feel like I’m watching Life. (Use control-C to stop it.)
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Feisty is now officially at end-of-life.
Looking back through my build logs, I can see that my desktop spent 34 hours, 44 minutes, and 46 seconds building 255 security updates. (And 25 hours, 40 minutes, 13 seconds doing 249 builds during the Feisty devel window.) As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.
As a correction to the Edgy EOL post, my desktop actually spent 50:59:40 doing 322 security builds and 04:14:23 doing 84 devel builds.
Current standings:
dapper: 49:42:36
gutsy: 43:14:36
hardy: 166:11:15
intrepid: 70:24:52
As mentioned, these numbers are mixed devel/security times.
Thank you Feisty! You were much more stable than Edgy, even if we didn’t see eye-to-eye about wifi connectivity.
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Major props to NCommander for taking on the painful experiment of getting the entire Ubuntu Intrepid archive rebuilt with PIE on amd64. After getting all the other hardening defaults enabled for Intrepid, PIE is the last on the original list for enabling “by default”. Due to the overhead of PIE on i386, it’s really only an option on architectures with lots of general registers.
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Here are my notes on growing a KVM disk image’s root filesystem. I had a few 4G partitions that really needed to be bigger. This shows how to get a report on the sizes of the disk images, convert them to raw, work on the partition tables, grow the root filesystem, and rebuild the swap partition with the original UUID. With some work, it could probably become fully scripted, but since the partition layout may not always be the same from VM to VM, the “fdisk” step needs human interaction to delete and rebuild the partition table. Note that the method below also maintains the sparseness of the images.
# Look for files to change for i in /vmware/*/*{vmdk,qcow2}; do qemu-img info $i; done ... # Pick one... cd dir... ORIG=64bit-Ubuntu-7.10-desktop.vmdk SIZE=8G ORIG_TYPE=$(echo $ORIG | awk -F. '{print $NF}') TARGET_TYPE="qcow2" TARGET_BASE=$(basename "$ORIG" ."$ORIG_TYPE") TARGET_RAW="$TARGET_BASE".raw TARGET="$TARGET_BASE"."$TARGET_TYPE" qemu-img convert -f "$ORIG_TYPE" "$ORIG" -O raw "$TARGET_RAW" trunc "$TARGET_RAW" "$SIZE" sudo kpartx -a "$TARGET_RAW" SWAP_PART=$(for i in /dev/mapper/loop0p*; do sudo vol_id $i | \ grep -q ^ID_FS_TYPE=swap && echo $i; done | head -n 1) UUID=$(sudo vol_id "$SWAP_PART" | grep ^ID_FS_UUID= | cut -d= -f2) sudo kpartx -d "$TARGET_RAW" # use losetup otherwise fdisk doesn't know cylinder count sudo losetup /dev/loop0 "$TARGET_RAW" # FIXME: Need to automate fdisk (detect swap partition size, etc) # I'm deleting the swap and growing the root partition, then re-adding swap sudo fdisk /dev/loop0 sudo losetup -d /dev/loop0 sudo kpartx -a "$TARGET_RAW" sudo e2fsck -f /dev/mapper/loop0p1 sudo resize2fs /dev/mapper/loop0p1 sudo mkswap -U "$UUID" "$SWAP_PART" sudo kpartx -d "$TARGET_RAW" qemu-img convert -f raw "$TARGET_RAW" -O "$TARGET_TYPE" "$TARGET" rm "$TARGET_RAW" # FIXME: change disk image path sudo vi /etc/libvirt/qemu/THING # FIXME: have the daemon notice the file change sudo /etc/init.d/libvirt-bin restart if [ "$ORIG" != "$TARGET" ]; then rm "$ORIG"; fi
The “trunc” command above is based on my network backups post, but is now a general script I use:
#!/usr/bin/perl # Copyright (C) 2006-2008 Kees Cook <kees@outflux.net>, License: GPLv3 use strict; use warnings; my $filename = $ARGV[0]; die "Need valid size also\n" unless ($ARGV[1] =~ /^(\d+)([KMG])$/); my $size = $1 + 0; my $multiplier = $2; $size *= 1024 if $multiplier =~ /^[KMG]$/; $size *= 1024 if $multiplier =~ /^[MG]$/; $size *= 1024 if $multiplier =~ /^[G]$/; #die "Not trunc'ing existing file\n" if (-e $filename); die "$filename: $!\n" if (!open(FILE,">>$filename")); die "seek: $!\n" if (!(seek(FILE,$size,0))); die "truncate: $!\n" if (!(truncate(FILE,$size))); die "close: $!\n" if (!(close(FILE)));
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Miguel Ruiz asked about Ubuntu security repositories. Here’s how things are done:
The “security.ubuntu.com” archive contains explicitly only the “$RELEASE-security” pockets. It is included in all Ubuntu sources.list files so that the package manager knows what the most recent security release of a package will be.
The central “archive.ubuntu.com” server (and all the Ubuntu mirrors) also contain the “$RELEASE-security” pockets, in addition to the rest of the archive (and will continue to have all pockets — which answers the core of Miguel’s question). While mirrors are not required to mirror the -security pocket, it certainly helps with the load on the primary Ubuntu archive servers.
The “security.ubuntu.com” entry is last in sources.list, giving the option of pulling an updated package from an earlier mentioned mirror (resulting in a faster download for the user, and less bandwidth used by the central Ubuntu archive servers). In the case that the mirror is behind, the package is available directly from “security.ubuntu.com”. In this way, mirrors cannot (accidentally or intentionally) “go rogue” — the latest security updates are always visible on the security archive server.
© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
Powered by WordPress