Here it doesn’t complain about connecting to “outflux.net” when the cert has a CN for “www.outflux.net”:

echo QUIT | openssl s_client -CApath /etc/ssl/certs \
  -connect outflux.net:443 2>/dev/null | egrep "subject=|Verify"

subject=/CN=www.outflux.net
    Verify return code: 0 (ok)

git log --author='Kees Cook' --pretty=oneline | \
while read commit name; do \
    echo $(git tag --contains $commit | head -n1): "$name"; \
done

Which lets me know where my code is with respect to releases:

v2.6.33: x86, mm: Report state of NX protections during boot
v2.6.33: sysctl: require CAP_SYS_RAWIO to set mmap_min_addr
v2.6.32: proc: fix reported unit for RLIMIT_CPU
v2.6.31: modules: sysctl to block module loading
...

So far, the best attempt at stalling the process was to set CPU affinity, set its scheduling policy (IDLE), drop the priority value fully (19), and then run a CPU hog with the same CPU affinity with a very high priority (-20).

Staller: sudo schedtool -a 0 -N -n -20 -e /tmp/spin-cpu
Stallee: schedtool -a 0 -D -n 19 -e /usr/bin/sudo -s

The hope was to then run “sudo gdb /usr/bin/sudo $(pidof sudo)“, but it seems that this still isn’t enough to make the exec of sudo totally stall while the “spin-cpu” process is running — it certainly executes more slowly, but I want it to stop.

I have this feeling like I’m missing something obvious about how to accomplish this gdb session sanely. I wonder if I can get gdb to switch targets across a child exec, i.e. run gdb as root on a program that fully drops privs, but then execs sudo. Guess it’s time to go read the gdb manual some more…

Check for yourself. (Run it with --verbose for useful details.)

Out of 7511 Ubuntu bugs Brian Murray collected for me that included /proc/cpuinfo files, there were 7270 unique contents (which surprised me — I was expecting this to be much lower).

• 5 (0.07%) were non-x86.
• 1 (0.02%) had corrupted contents (likely due to a search/replace in apport gone awry).
• 5670 (77.99%) had NX (this also surprised me — I was not expecting it to be so high).
• 337 (4.64%) lacked PAE, and so cannot have NX (I didn’t expect this to be so low; Ubuntu bug reporters must have relatively recent hardware overall).
• 595 (8.18%) had PAE and correctly lacked NX (I didn’t expect this to be so high — PAE without NX is a bit more common than I’d hoped; hopefully these systems are running 32bit kernels to at least get the partial NX emulation).
• 662 (9.1%) had PAE but incorrectly lacked NX.

It’s this last group of systems I’m hoping to get fixed through education.

$ ls -la /bin/ping
-rwsr-xr-x 1 root root 35680 2009-11-05 00:41 /bin/ping
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms
…
$ sudo setcap CAP_NET_RAW=ep /bin/ping
$ getcap /bin/ping
/bin/ping = cap_net_raw+ep
$ ./ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.041 ms
…
$ dmesg | tail -n1
[212275.772124] warning: `/bin/ping’ has both setuid-root and effective capabilities. Therefore not raising all capabilities.

The best part is that the kernel will choose the set of least privileges when both setuid and capabilities exist. Easy way to transition!

While most TPM RNGs aren’t really heavy-duty hardware RNGs, they are at least a mild source of randomness. I’ll be using an entropy key eventually, but for now, the TPM can supplement my collected entropy.

/etc/default/rng-tools:

HRNGDEVICE=/dev/null
RNGDOPTIONS=”–hrng=tpm –fill-watermark=90% –feed-interval=1″

After it’s been running a bit:

Feb 8 19:10:51 linux rngd[13143]: stats: bits received from HRNG source: 6180064
Feb 8 19:10:51 linux rngd[13143]: stats: bits sent to kernel pool: 6166144
Feb 8 19:10:51 linux rngd[13143]: stats: entropy added to kernel pool: 4624608
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2 successes: 309
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2 failures: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Monobit: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Poker: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Runs: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Long run: 0
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS 140-2(2001-10-10) Continuous run: 0
Feb 8 19:10:51 linux rngd[13143]: stats: HRNG source speed: (min=5.207; avg=6.145; max=6.200)Kibits/s
Feb 8 19:10:51 linux rngd[13143]: stats: FIPS tests speed: (min=66.925; avg=75.789; max=112.861)Mibits/s
Feb 8 19:10:51 linux rngd[13143]: stats: Lowest ready-buffers level: 0
Feb 8 19:10:51 linux rngd[13143]: stats: Entropy starvations: 308
Feb 8 19:10:51 linux rngd[13143]: stats: Time spent starving for entropy: (min=3150263; avg=3178447.994; max=3750848)us

And now the kernel entropy pool is high:

$ echo $(cat /proc/sys/kernel/random/entropy_avail)/$(cat /proc/sys/kernel/random/poolsize)
3968/4096

Bottom line: it seems that Google, among other methods, is likely wardriving while photographing for Street View. They are now able to pinpoint wifi access points if they happened to see it while driving through your city.

I’m really rather astonished that no one is freaking out about this; I’m a bit unnerved. I implemented the location-of-your-wifi API quickly, so I could terrify myself further. You can do lookups via my location website too, if you want.

UPDATE: yeah, it would seem to be crowd-sourced wifi and cell tower triangulation data. I should say “Google is WarCrowding”.

The MythTV wiki instructions were very good. However, I didn’t like that it was a closed-source binary doing network traffic. (While “system” doesn’t show up in “readelf -r” output, that doesn’t mean it isn’t doing direct syscalls, or manually finding the “system” offset in the libc library, or is vulnerable to overflows, and on and on.) So, to put my mind at ease, I decided to confine it in an AppArmor profile:

#include <tunables/global>

/usr/bin/huludesktop {
#include <abstractions/gnome>
#include <abstractions/audio>
#include <abstractions/nameservice>

/etc/huludesktop/** r,
@{HOME}/.huludesktop rwkl,
@{HOME}/.local/share/.huludesktop.data rwkl,
@{HOME}/.macromedia/Flash_Player/macromedia.com/support/flashplayer/sys/*.hulu.com/** r,
@{HOME}/.macromedia/Flash_Player/#SharedObjects/ r,
@{HOME}/.macromedia/Flash_Player/#SharedObjects/*/*.hulu.com/ rw,
@{HOME}/.macromedia/Flash_Player/#SharedObjects/*/*.hulu.com/** rwkl,

# MythTV is already managing the screensaver
deny /usr/bin/xdg-screensaver x,
}

Additionally, I disabled its executable stack, which seems to serve no purpose:
$ sudo execstack -c /usr/bin/huludesktop

Or, as my firewall reported this morning:

Dec 25 04:39:18 firewall kernel: [1054241.000084] sd 2:0:0:0: [sda] ABORT operation started
...
Dec 25 04:40:10 firewall kernel: [1054292.072173] raid1: sdb2: redirecting sector 3490144 to another mirror


I guess I’m getting my firewall a new hard drive for Christmas. :)

v4l2src ! ffmpegcolorspace ! vertigotv ! ffmpegcolorspace

Now when Empathy video-chatting with a friend, you can give them a headache!

Or give yourself a headache by trying it directly from the command line:

gst-launch v4l2src ! ffmpegcolorspace ! vertigotv ! ffmpegcolorspace ! xvimagesink

Feel free to replace “vertigotv” with any other or more of the video effects listed in “gst-inspect effectv“.

Here’s me with edgetv ! vertigotv:

• ASLR of mmap allocations
• ASLR of text/exec area
• ASLR of vdso
• ASLR of brk area

Stack is already randomized, it should be easy to do the rest! ;)

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:

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.

Since I was successful with porting the code and wiring up the Arduino, I figured I’d see if the tiny Arduino-clone called the “DorkBoard” would work with it too.

Later in the weekend I grabbed a AAA-battery holder and hooked that up so the eye is untethered from the USB power source. Next up, coding the pesky self-awareness.

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.)

$ sudo -s
# echo "deb http://archive.canonical.com/ jaunty partner" >> /etc/apt/sources.list
# sudo apt-get update
# apt-get --no-install-recommends install $(grep ^Package /var/lib/apt/lists/*{multiverse,partner}*Packages | awk '{print $NF}' | sort -u | egrep -v '^(ttf-lucida|crafty-books-medium|crafty-books-small|festvox-rablpc8k|kxmame|funguloids|ltsp-controlaula|mplayer-nogui|ora2pg|python-pygpu|sdlmame|sdlmame-tools|linux-rt|e-uae|e-uae-dbg|sun-java5-fonts|sun-java6-fonts)$')


Since we want to minimize free packages, I added --no-install-recommends since it would only pull in free stuff (since I was already installing all of multiverse and partner directly). I tried to solve conflicts by making choices that would install the maximum number of packages. After installing 10G worth of packages, I had my results:

# vrms | grep ^[a-z0-9] | wc -l
514
# vrms | tail -n2
342 non-free packages, 15.2% of 2252 installed packages.
172 contrib packages, 7.6% of 2252 installed packages.


# 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.

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.

As more and more of the monolithic ExecShield kernel patch has been taken upstream (many thanks to Arjan van de Ven for pushing them), the patch in RedHat has been shrinking. Recently, Dave Jones split up the remaining pieces into logical chunks small enough that I could actually read it without going cross-eyed. From this, I ported the nx-emulation patches to Ubuntu’s kernel, and now they’re happily live in Karmic.

So, instead of this:

$ ./vulnerable-setuid-program $OVERFLOW_AND_SHELLCODE
# id
uid=0(root) gid=0(root) groups=0(root)

We get this:

$ ./vulnerable-setuid-program $OVERFLOW_AND_SHELLCODE
Segmentation fault (core dumped)
$ dmesg | tail -n1
[170131.763976] vulnerable-set[16278]: general protection ip:80489c5 sp:bfa3e330 error:0 in vulnerable-setuid-program[8048000+1000]

Though, as always, please just use 64bit instead. :)

Update: gave credit to PaX, thanks for the corrections!

Here is a script to find the monitor for the most recently added Sink, record from it, and shove it through “sox” to get a WAV instead of raw sound data (requires recent sox, Pulse, etc):

#!/bin/bash
WAV="$1"
if [ -z "$WAV" ]; then
    echo "Usage: $0 OUTPUT.WAV" >&2
    exit 1
fi
rm -f "$WAV"

# Get sink monitor:
MONITOR=$(pactl list | grep -A1 '^\*\*\* Source #' | \
    grep '^Name: .*\.monitor$' | cut -d" " -f2 | tail -n1)

# Record it raw, and convert to a wav
echo "Recording to $WAV ..."
echo "Close this window to stop"
parec -d "$MONITOR" | sox -t raw -r 44k -sLb 16 -c 2 - "$WAV"

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.

$ 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

I’m hugely excited to see that it looks like the game was built on Ubuntu Intrepid for both the .deb and .tar.gz packages:

$ strings -a WorldOfGoo.bin | grep -i gcc
...
GCC: (Ubuntu 4.3.2-1ubuntu12) 4.3.2


The bundled libraries appear to come from Gentoo:

$ strings -a libs/libogg.so.0 | grep -i gcc
...
GCC: (GNU) 4.2.3 (Gentoo 4.2.3 p1.0)


OpenSSL (and libpng?) from Gentoo seem to have been statically linked into the binary:

$ strings -a WorldOfGoo
...
GCC: (GNU) 4.2.3 (Gentoo 4.2.3 p1.0)
_x86_AES_encrypt
...


What I’m so very excited about is that third party software producers are using Ubuntu for their releases. This means they get all the security and code-quality improvements that are built into the Ubuntu compiler for free:

$ objdump -CR WorldOfGoo.bin | grep _chk
...
084043f0 R_386_JUMP_SLOT __memcpy_chk


Many thanks to Maks Verver for doing the porting. I’m really enjoying the demo. Also, I can see your devel path! :)

$ strings -a WorldOfGoo.bin | grep openssl
OPENSSLDIR: "/home/maks/Projects/wog/libs/openssl-0.9.8j-linux-i386/ssl"
...


All this said, it may be that they’re actually only compiling pieces (like the Open Dynamics Engine, which seems to contain the bulk of the *_chk calls) on Ubuntu (or using .a files from a distro-compiled library that enables hardening only in builds — RedHat, SuSE), but doing the .deb and .tar.gz project linking on Ubuntu (which is why the compiler name shows up in the resulting binary). The RPM shows the *_chk functions too — actually the disassembly is identical between deb and RPM, which would imply that only final linking was done on the native distros but compiled elsewhere. I’d love to hear more details if Maks stumbles on this blog. :)

# 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. :)

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.

1. 0.717338929043293 lsscsi
2. 0.612729234088457 nevow
3. 0.561151781356762 powertop
4. 0.431034482758621 language-pack-tk-base
5. 0.431034482758621 language-pack-se-base

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.