codeblog code is freedom — patching my itch

7/31/2009

blocking module loading

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 11:47 am

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 3.0 License.
Creative Commons License

7/16/2009

Diminished Dapper

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 10:18 am

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 3.0 License.
Creative Commons License

5/14/2009

partial NX emulation in Ubuntu

Filed under: Security,Ubuntu — kees @ 9:18 am

Now available for early testing, Ubuntu Karmic Alpha 1 has a kernel feature I’ve long wanted in Ubuntu: NX emulation. Basically, if your hardware lacks NX support, the kernel will emulate the feature using memory segment limits and ordering. This was AFAIBT originally developed by PaX, and a similar version (with histories including work by Solar Designer and maybe OpenBSD?) has been carried in RedHat/Fedora for a while now (under the larger project called “ExecShield”, covering multiple protection technologies).

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!

© 2009, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

4/17/2009

Goodbye Gutsy

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 3:05 pm

(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 3.0 License.
Creative Commons License

4/9/2009

CODEGATE 2009 ran Ubuntu Intrepid

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 9:05 pm

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 3.0 License.
Creative Commons License

1/1/2009

happy new year, RIP md5

Filed under: Blogging,Debian,Security,Ubuntu,Ubuntu-Server — kees @ 10:59 am

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 3.0 License.
Creative Commons License

12/3/2008

bogosec run on intrepid main

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 10:16 am

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:

  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.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

11/21/2008

make your BIOS love security

Filed under: Security,Ubuntu,Ubuntu-Server — kees @ 1:39 pm

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 3.0 License.
Creative Commons License

11/18/2008

md5 lookups for 4 chars and common words

Filed under: Blogging,Debian,Security,Ubuntu,Web — kees @ 8:19 pm

Here’s a fun link. This site appears to have seeded their md5 hash list with all lower case character strings of 4 characters or fewer and many english words (probably from some large dictionaries), and they seem to be adding more as they go. This makes me want to put up an interface to the 7 character alpha-numeric-plus-many-special-chars rainbow table I’ve got. But searching the 500G table for a single hash takes… a while. I’d need to batch it up. Go-go-gadget web 2.0!

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

11/9/2008

“rooting” the HTC G1 Android

Filed under: Blogging,Debian,Embedded,Security,Ubuntu,Vulnerabilities — kees @ 10:27 am

People noticed that running telnetd seemed to run as root. Later it was discovered that everything you typed was being run by the root user also. So, that ends the first mystery: when you typed “telnetd” both the Terminal user and root ran it. It would fail (without error messages) for the Terminal user, and run successfully for the root user. So now, the question is, what the f is a root shell doing mirroring user input?!

So, there is a much easier way to get root that doesn’t require network connectivity. While the /sdcard mount point is nosuid,noexec, it’ll still run scripts if you explicitly direct them to run. It seems that the weird background root shell doesn’t understand the alt-keys, so it can only run stuff that can be typed without using alt, shift, etc. So, put the following in /sdcard/pwn:


mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cd /system/bin
cat sh > sh.root
chmod 4755 sh.root
mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system

You can either do this by dropping the file in place over USB mass storage, or you can type it via the Terminal using “cat“. (Rebooting here might help get the root shell in a sane state.) Finally, just navigate there without slashes and run the script:


$ cd sdcard
$ sh pwn

You’ll see lots of errors (but these are only from the Terminal user). The script is, however, run by the root shell too. You can verify the results:


$ ls -l /system/bin/sh*
-rwxr-xr-x root          shell     86936 2008-09-13 00:13 sh
-rwsr-xr-x root          root      86936 2008-11-09 10:12 sh.root

Next up: cross-compiling a little helper to elevate to real UID 0, and require a password to keep malware from looking for setuid shells.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

11/3/2008

days since last incident…

Filed under: Blogging,Debian,Networking,Security,Ubuntu,Ubuntu-Server — kees @ 11:15 am

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 3.0 License.
Creative Commons License

10/21/2008

Feisty Finale

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 3:59 pm

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 3.0 License.
Creative Commons License

9/4/2008

all PIE distro

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 2:00 pm

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 3.0 License.
Creative Commons License

8/20/2008

Ubuntu security repository structure

Filed under: Blogging,Security,Ubuntu,Ubuntu-Server — kees @ 12:04 pm

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 3.0 License.
Creative Commons License

4/25/2008

Farwell Edgy

Filed under: Blogging,Security,Ubuntu — kees @ 6:39 pm

Edgy is now officially at end-of-life.

Looking back through my build logs, I can see that my desktop spent 55 hours, 14 minutes, and 3 seconds on 406 builds related to edgy-security updates I was involved in publishing. These times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc. Comparing to my prior post on this topic, here are the standings for other releases:

dapper: 44:48:24
feisty: 58:49:04
gutsy: 37:06:08
hardy: 86:25:58

Hmm… I think my hardy numbers include devel builds times… I’ll have to sort that out. :)

Thank you Edgy! I will remember you for your wonderful default -fstack-protector.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

3/16/2008

SELinux in Hardy

Filed under: Security,Ubuntu — kees @ 1:32 pm

Hardy has seen a major overhaul in the SELinux department. Prior to the Hardy UDS, the folks at Tresys had contacted me, asking “why doesn’t SELinux work with Ubuntu?” and I basically said, “because no one has given it any attention, yet — feel free to help out.” And so they did! :)

As a result, if AppArmor isn’t the MAC system you want, you can now install a functional SELinux system on Ubuntu with just a simple “sudo apt-get install selinux”.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

3/5/2008

swapping encryption, hurting your head

Filed under: Security,Ubuntu — kees @ 11:18 am

Last week Soren helped me move my manually cryptsetup’d swap partition into the initramfs logic so that I could hibernate. Bottom line was:

  1. Create /etc/initramfs-tools/conf.d/cryptroot for your partition, based on the logic and defaults in /usr/share/initramfs-tools/scripts/local-top/cryptroot.
  2. Convert the existing encrypted swap to the new configuration.
  3. Update initrd, reboot, enjoy.

Assuming your swap partition (in encrypted form) is stored at /dev/laptopvg/swaprawlv, and you want your accessible swap partition as /dev/mapper/swap, here are the above steps in detail:

Doing step 1 is simple, we’re assuming the defaults from the cryptroot script above:

    echo source=/dev/laptopvg/swaprawlv target=swap > /etc/initramfs-tools/conf.d/cryptroot
    

Step 2 hurt my head. Make sure you’ve unmounted your swap before attempting this, or you can destroy the partition contents. The parameters come from the cryptroot script again:

    swapoff /dev/mapper/swap
    vol_id /dev/mapper/swap
    cryptsetup -c aes-cbc-essiv:sha256 -h sha256 -s 256 create swap2 /dev/laptopvg/swaprawlv
    dd if=/dev/mapper/swap of=/dev/mapper/swap2 bs=4k
    cryptsetup remove swap
    vol_id /dev/mapper/swap2
    

Step 3 is simple again:

    update-initramfs -u
    shutdown -r now
    

Ta-da!

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

2/20/2008

OSS Security – OSU CS419 2008

Filed under: Security,Ubuntu — kees @ 5:36 pm

Today I gave my presentation on Open Source Security to the Open Source class at Oregon State University. Along with the presentation is a collection of examples of bad (and good) programs ranging from XSS, CSRF, temp races, system() and SSL misuse, stack and heap memory corruption, format strings, and all sorts of other things I could think of. I gave this presentation in 2007 and was again honored to be asked back in 2008. I think more schools need to be teaching dedicated Open Source classes, and I’m pleased to help out. I’m hoping people will take away a few good ideas that will contribute to them producing safe code.

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

1/15/2008

full ASLR in Hardy

Filed under: Security,Ubuntu — kees @ 11:07 am

Thanks to all the people that worked on it from the coding, breaking, testing, and refactoring, Hardy is now sporting the last piece of full Address Space Layout Randomization support. ASLR has been mostly unchanged since Dapper, when the first bits of ASLR went in: stack and mmap (library) randomization. Those changes made simple stack overflow, heap overflow, and return-into-libc attacks much less trivial. Now in Hardy, with the VDSO and brk (text) randomization, things are even more difficult for attackers to exploit.

For binaries that have been compiled with -pie (Position Independent Executable), the kernel is finally able to take advantage of it. As an example, openssh is already using this compile option, and the results are easy to see. Here are the processes from two SSH connections:

$ pstree -lp | grep sshd
        |-sshd(7243)-+-sshd(9136)---sshd(9140)---bash(9142)-+-grep(15380)
        |            +-sshd(9181)---sshd(9185)---bash(9186)

If we examine the memory layout of both sshd processes (9136 and 9181), we can see no user-space memory locations are shared:

$ sudo cat /proc/9136/maps
7ff69df86000-7ff69e0c6000 rw-s 00000000 00:09 34320                      /dev/zero (deleted)
7ff69e0c6000-7ff69e0c9000 r-xp 00000000 fe:15 480495                     /lib/security/pam_limits.so
...
7ff6a1fc8000-7ff6a1fd0000 rw-p 7ff6a1fc8000 00:00 0 
7ff6a1ff7000-7ff6a1ffa000 rw-p 7ff6a1ff7000 00:00 0 
7ff6a1ffa000-7ff6a1ffc000 rw-p 0001d000 fe:15 1040531                    /lib/ld-2.7.so
7ff6a1ffc000-7ff6a205b000 r-xp 00000000 fe:15 98598                      /usr/sbin/sshd
7ff6a225a000-7ff6a225d000 rw-p 0005e000 fe:15 98598                      /usr/sbin/sshd
7ff6a225d000-7ff6a2289000 rw-p 7ff6a225d000 00:00 0                      [heap]
7fffaa045000-7fffaa05a000 rw-p 7ffffffea000 00:00 0                      [stack]
7fffaa1fe000-7fffaa200000 r-xp 7fffaa1fe000 00:00 0                      [vdso]
...
$ sudo cat /proc/9181/maps
7f05a07b8000-7f05a08f8000 rw-s 00000000 00:09 35989                      /dev/zero (deleted)
7f05a08f8000-7f05a08fb000 r-xp 00000000 fe:15 480495                     /lib/security/pam_limits.so
...
7f05a47fa000-7f05a4802000 rw-p 7f05a47fa000 00:00 0 
7f05a4829000-7f05a482c000 rw-p 7f05a4829000 00:00 0 
7f05a482c000-7f05a482e000 rw-p 0001d000 fe:15 1040531                    /lib/ld-2.7.so
7f05a482e000-7f05a488d000 r-xp 00000000 fe:15 98598                      /usr/sbin/sshd
7f05a4a8c000-7f05a4a8f000 rw-p 0005e000 fe:15 98598                      /usr/sbin/sshd
7f05a4a8f000-7f05a4abb000 rw-p 7f05a4a8f000 00:00 0                      [heap]
7fffac877000-7fffac88c000 rw-p 7ffffffea000 00:00 0                      [stack]
7fffac9fe000-7fffaca00000 r-xp 7fffac9fe000 00:00 0                      [vdso]
...

The larger the memory space, the more effective ASLR is, so 64bit is the way to go. And, as always, using 64bit kernels automatically gives you the NX bit protections too. Running a 64bit Hardy system is going to rock. :)

© 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

12/21/2007

best universal remote evar

Filed under: Blogging,Security,Ubuntu — kees @ 6:16 pm

As a quick break from software, I spent a little time this evening soldering together my TV-B-Gone Kit. It was way fun to break out all my microelectronics gear. Gave me an excuse to clean up my desk. This thing is the silliest tool ever: it’s programmed with a mess of TV remote codes — but only those to turn off TVs. So, just point at a TV near you, hit the button, and it’ll almost certainly turn off.

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

9/24/2007

0x41 0x41 0x41 0x41

Filed under: Security,Ubuntu,Vulnerabilities — kees @ 8:34 pm

When trying to find buffer overflows, it is common practice to try and fill memory with lots of “A” characters. I first saw this when learning basic stack smashing techniques from Smashing the Stack for Fun and Profit, and have long wondered who did it first. Ever since, I’ve always used long strings of “A”s too (sometimes “B”s), and only recently started using better things like Metasploit’s pattern generator and offset reporter.

I’m fairly used to seeing things like this from my gdb sessions:

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
(gdb)

It means I’ve managed to gain control of the instruction pointer, and I’m now to the stage of needing to locate and deliver a shellcode.

Over the weekend I had the pleasure of causing my kernel to do something similar, via an unprivileged userspace process, using the vulnerability discovered by Wojciech Purczynski:

[119647.578349] general protection fault: 0000 [3] SMP
[119647.578357] CPU 0

[119647.578759] Code: Bad RIP value.
[119647.578774] RIP [<4141414141414141>]

I hadn’t had an opportunity to play with kernel shellcode before, so I ended up learning a lot from Brad Spengler. Before the day was up, I was left staring at a root shell.

This was a nasty bug. Luckily, it’s “only” a local exploit, and only for x86_64 kernels. But that’s still a very large number of installations. Please make sure your x86_64 machines are patched against CVE-2007-4573 (for Ubuntu, this is USN-518-1).

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

9/15/2007

catching stack overflows in gdb as they happen

Filed under: Reverse Engineering,Security,Ubuntu — kees @ 8:57 pm

Recently I was trying to help debug a stack overflow crash in wpa_supplicant. The trouble with a stack crash is that you end up without a useful call history since the stack is left partially wrecked. The compiler code for detecting stack overflows (SSP), sets up a canary value between the local variables of the function and the stack frame. When the function exits, it tests this canary value and aborts if it doesn’t match what it is expecting. So, logically, to catch the stack overflow, gdb needs to be set up in a way to watch the canary location too. Since the canary is only valid while in the function, gdb must be set up to have a memory watch only when the function is called.

Here is the function preamble:

0x08081940 <wpa_driver_wext_get_scan_results+0>:        push   %ebp
0x08081941 <wpa_driver_wext_get_scan_results+1>:        mov    %esp,%ebp
0x08081943 <wpa_driver_wext_get_scan_results+3>:        push   %edi
0x08081944 <wpa_driver_wext_get_scan_results+4>:        push   %esi
0x08081945 <wpa_driver_wext_get_scan_results+5>:        push   %ebx

Save registers, prepare %ebp.

0x08081946 <wpa_driver_wext_get_scan_results+6>:        mov    $0x1000,%ebx
0x08081951 <wpa_driver_wext_get_scan_results+17>:       mov    0x8(%ebp),%eax
0x08081954 <wpa_driver_wext_get_scan_results+20>:       mov    0xc(%ebp),%edx
0x08081957 <wpa_driver_wext_get_scan_results+23>:       lea    0xffffffb0(%ebp),%esi

Make room for local variables, copy some function arguments and local variables into registers.

0x0808195a <wpa_driver_wext_get_scan_results+26>:       mov    %gs:0x14,%ecx
0x08081961 <wpa_driver_wext_get_scan_results+33>:       mov    %ecx,0xffffffec(%ebp)
0x08081964 <wpa_driver_wext_get_scan_results+36>:       xor    %ecx,%ecx

Here’s the stack canary getting set, and the register cleared. It’s saved at %ebp minus 0x14 (0xffffffec signed is -0x14):

(gdb) printf "0x%x\n", 0-0xffffffec
0x14

Now for the function play-out:

0x08081a37 <wpa_driver_wext_get_scan_results+247>:      mov    0xffffffec(%ebp),%edx
0x08081a3a <wpa_driver_wext_get_scan_results+250>:      xor    %gs:0x14,%edx
0x08081a41 <wpa_driver_wext_get_scan_results+257>:      jne    0x8081eae <wpa_driver_wext_get_scan_results+1390>

There is the canary check.

0x08081a47 <wpa_driver_wext_get_scan_results+263>:      add    $0xec,%esp
0x08081a4d <wpa_driver_wext_get_scan_results+269>:      pop    %ebx
0x08081a4e <wpa_driver_wext_get_scan_results+270>:      pop    %esi
0x08081a4f <wpa_driver_wext_get_scan_results+271>:      pop    %edi
0x08081a50 <wpa_driver_wext_get_scan_results+272>:      pop    %ebp
0x08081a51 <wpa_driver_wext_get_scan_results+273>:      ret    
...
0x08081eae <wpa_driver_wext_get_scan_results+1390>:     call   0x804bdc8 <__stack_chk_fail@plt>

Release local stack, pop saved registers and return. Nearer the end is the call to __stack_chk_fail when the canary doesn’t match.

So, to watch the canary, we need to set up a memory watch after it as been set, and tear it down before we leave the function. Respectively, we can use addresses 0x08081964 and 0x08081a3a (in bold above):

(gdb) br *0x08081964
Breakpoint 1 at 0x8081964
(gdb) br *0x08081a3a
Breakpoint 2 at 0x8081a3a

At the first breakpoint, we set a memory watch using a gdb-local variable, based on %ebp (we can’t use %ebp directly since it will change in lower function calls):

(gdb) commands 1
Type commands for when breakpoint 1 is hit, one per line.
End with a line saying just "end".
>silent
>set variable $cow = (unsigned long*)($ebp - 0x14)
>watch *$cow
>cont
>end

Since I couldn’t find an easy way to track the memory watch number that was created during the first breakpoint, I just built a gdb counter, and deleted the memory watch when leaving, since I could predict gdb’s numbering (first watch will be “3”, following our breakpoints 1 and 2):

(gdb) set variable $count = 3
(gdb) commands 2
Type commands for when breakpoint 2 is hit, one per line.
End with a line saying just "end".
>silent
>delete $count
>set variable $count = $count + 1
>cont
>end

Now we can run, and wait for the canary to get overwritten:

(gdb) cont
Continuing.
Hardware watchpoint 3: *$cow
Hardware watchpoint 4: *$cow
...
Hardware watchpoint 12: *$cow
Hardware watchpoint 13: *$cow
Hardware watchpoint 13: *$cow

Old value = 4278845440
New value = 4278845546
0x0804eae6 in ?? ()

We see the canary value is 0xFF0A0000 getting it’s little-endian first byte overwritten to FF0A006A. We catch it before it has wrecked the stack, and we can see very clearly where we are:

(gdb) bt
#0  hexstr2bin (hex=0x080a239d "6151663870517a74", buf=0x080a2395 "aQf8pQzt00000000j", len=8)
    at ../src/utils/common.c:88
#1  0x08082297 in wpa_driver_wext_get_scan_results (priv=0xb7dd816c, 
    results=0x080a239d, max_size=0x79)
    at ../src/drivers/driver_wext.c:1383
...
(gdb) x/1i $eip      
0x804eae6 <hexstr2bin +54>:      addl   $0x1,0xfffffff0(%ebp)

On a closer look at the source, we realize wext_get_scan_custom got inlined into the function (it was static and only called from one place, so the compiler optimized it). Further tracking in the source shows that the “16” value passed in should actually be “8” (the limit of the destination, not the source, buffer size).

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

8/7/2007

flag captured again

Filed under: Reverse Engineering,Security — kees @ 4:22 pm

I thought last year was going to be a fluke. Somehow we managed to do it again. Team 1@stPlace won DefCon Capture the Flag for a second year in a row. If my sources are correct, this is the first repeat CTF winner at DefCon since the Ghetto Hackers. I’m honored to be on such a very talented team. I’ve only just recently recovered from getting almost no sleep for 3 days. :)

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

4/13/2007

Farewell Breezy

Filed under: Blogging,Security,Ubuntu — kees @ 6:46 pm

Breezy is now officially at end-of-life.

Looking back through my build logs, I can see that my desktop spent 18 hours, 49 minutes, and 4 seconds on 108 builds related to the roughly 64 breezy-security updates I was involved in publishing. So far, Dapper is at 132 builds totaling 19:59:40, and Edgy is at 142 builds totaling 23:32:28. These times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the PPC machine, etc. Even if it’s a bit incomplete, I think it’s fun to be able to point to some hard numbers about CPU time spent on Breezy updates. :)

Thank you Breezy! You have housed my MythTV installation very nicely, but now it’s time for some long over-due upgrades…

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

4/2/2007

AppArmor now in Feisty

Filed under: Security,Ubuntu — kees @ 11:03 am

With the help of Magnus Runesson, Jesse Michael, Martin Pitt, and many others, I’ve got AppArmor packaged and uploaded into Feisty universe. Prior to this, admins interested in a Mandatory Access Control system in Ubuntu only had SELinux available; now we have more of a choice. For anyone wanting to try out AppArmor, you will need to compile the modules, and install the base packages:

sudo apt-get install apparmor-modules-source dpatch
sudo m-a -v -t prepare
sudo m-a -v -t build apparmor-modules
sudo m-a -v -t install apparmor-modules
sudo apt-get install apparmor apparmor-utils apparmor-profiles libterm-readline-gnu-perl

With the default profiles, you can see one quick example of a confined process. Try doing this:

ping localhost >/dev/null &
sudo ps aZ | grep ping

In the first column, you should see what profile is being used to confine the process:

/bin/ping 14351 pts/14 S 0:00 ping localhost
unconstrained 15381 pts/14 S+ 0:00 grep ping

The list of active profiles can be seen as root in /sys/kernel/security/apparmor/profiles, which are loaded from /etc/apparmor.d/.

To confine a process, use aa-autodep and aa-logprof. For example, I wanted to confine my PDF document browser to only use /tmp (since I tend to only use it when browsing PDFs online):

  • First, I create an empty profile in “complain” mode: sudo aa-autodep evince
  • Next, I run evince like I normally would, including as many actions as I can think of (printing, preferences, help, etc). Watching the output of dmesg you can follow the trail of all the actions evince is taking. When I’m finished, I quit evince.
  • Next, I run aa-logprof, which runs through all the kernel audit output and offers suggestions on what to allow from evince. Where appropriate, I select “abstrations” for things like Gnome, DNS, fonts, tmp dir usage, etc. When a whole directory tree should be allowed, I double-glob the path (/usr/share/evince/**). Once all the items from the log have been processed, the profile is saved.
  • Finally, I enable the profile with aa-enforce evince. Any disallowed actions will show up in the kernel logs.

Check out the resulting profile for evince.

Now if I end up reading a malicious PDF that takes advantage of some currently-unknown vulnerability in evince, it will be confined to the above AppArmor profile, unable to exec new processes, and only able to write to the Gnome preferences for evince. (It’s also unable to read files out of /home, so that the above profile may be way too strict for common usage. And to even get caught by AppArmor, the imaginary exploit would have to avoid the randomized stack, randomized heap, stack protector, and, since I’m running 64bit, the NX processor bit.)

Be aware, this is still a new bit of packaging for Ubuntu, so you may run into sneaky gotchas. If that happens, please open a bug.

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

1/23/2007

CVE links via Greasemonkey

Filed under: Blogging,Security,Ubuntu,Web — kees @ 10:00 pm

I spend a good bit of time reading CVEs but their entries are plain text, without links associated with their various recorded URLs. I’m annoyed at having to select/paste to load a URL, so I had to go code a work-around. :)

Since MozDev‘s “linkify.user.js” was a bit heavy-handed, I wrote up a quick hack based on similar code to only look at mitre.org’s LI tags: “cve-links.user.js“.

© 2007, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

12/7/2006

paranoid browsing with squid

Filed under: Security,Ubuntu — kees @ 11:40 pm

As Carthik says, the SSH SOCKS option is a great way to quickly tunnel your web traffic. A word of caution for the deeply paranoid: all your DNS traffic is still in the clear. While the web traffic and URLs aren’t sniffable any more, curious people can still get a sense for what kinds of stuff you’re browsing, based on domain names. (And for the really really paranoid: if you’re on open wireless, your DNS lookups could get hijacked, causing you to browse to look-alike sites ready to phish your login credentials.)

Luckily, with SOCKS5 Firefox can control which side of the proxy handles DNS lookups. By default, it does the lookups locally resulting in the scenario above. To change this, set network.proxy.socks_remote_dns = true in about:config. This makes the SOCKS proxy more like a regular proxy, where DNS is handled by the remote end of the tunnel.

Update: Oops, as the title hints, I was going to talk about Squid. But then I didn’t. It’s pretty cool too. Carry on…

© 2006 – 2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

8/7/2006

flag captured

Filed under: Reverse Engineering,Security — kees @ 11:19 pm

I can’t believe it. We won DefCon CTF. I have no idea what to say. It just all came together this year. Great team, great contest.

And to make it even sweeter, since CTF is a “Black Badge” contest, I never have to pay to get into DefCon again! Although, at this point, I might pay several years worth of admission in exchange for lots of time to sleep. :)

UPDATE: nice write-up at the U of Florida.

© 2006, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

7/29/2006

encrypted network filesystems

Filed under: Networking,Security — kees @ 11:59 am

I run a machine in a colo across the country from me, and I wanted to have some backups closer to the machine. So I signed up for a NAS login with my provider. Since I didn’t want to leave all my files sitting on their disks in the clear, I built up an encrypted volume over the network. It’s not fast, but it works.

Here were the setup steps:

  1. mkdir -p /mnt/nas-raw /mnt/backups
  2. smbmount //backup.server.at.my.isp/mount.source.path /mnt/nas-raw -o username=myaccount,password=mypassword
  3. modprobe loop && sleep 2
  4. dd if=/dev/zero of=/mnt/nas-raw/volume bs=32k
  5. losetup /dev/loop0 /mnt/nas-raw/volume
  6. cryptsetup create crypt-backups /dev/loop0 –cipher=aes-cbc-essiv:sha256
  7. Type volume pass-phrase
  8. mkfs.ext3 /dev/mapper/crypt-backups
  9. mount /dev/mapper/crypt-backups /mnt/backups

To unmount it:

  1. umount /mnt/backups
  2. cryptsetup remove crypt-backups
  3. losetup -d /dev/loop0
  4. umount /mnt/nas-raw

And then to remount it later:

  1. smbmount //backup.server.at.my.isp/mount.source.path /mnt/nas-raw -o username=myaccount,password=mypassword
  2. modprobe loop && sleep 2
  3. losetup /dev/loop0 /mnt/nas-raw/volume
  4. cryptsetup create crypt-backups /dev/loop0 –cipher=aes-cbc–essiv:sha256
  5. Type volume pass-phrase
  6. mount /dev/mapper/crypt-backups /mnt/backups

By scripting the “remount” steps, I can actually echo the volume password into an ssh connection:

echo ‘my volume pass-phrase here’ | ~/bin/do-crypto-mount
ssh root@colo.machine.isp “/etc/dirvish/dirvish-cronjob && df -h /mnt/backups”
~/bin/do-crypto-umount

Very handy!

Update: I added the --cipher option to include the essiv type, which should be used.

© 2006 – 2008, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

7/28/2006

airodump channel hopping

Filed under: Networking,Security — kees @ 7:14 am

The “airodump” tool, part of the aircrack wireless analysis suite, is like “tcpdump”, except that it can perform channel hopping. Since channel hopping is a “lossy” way to do wireless sniffing (you’re only listening on each channel for a few hundred milliseconds before moving on to the next channel), it doesn’t make sense to listen to channels that you know will contain no traffic. However, there was no way to specify a range of channels. airodump would either listen on 1 channel or hop across all channels.

I wrote a patch to allow for a comma-separated list of channels to be specified. Now I can tell airodump to spend all of its hopping time on 6, 11, and 1, for example:

airodump ath0 /tmp/ath0-logs 6,11,1

UPDATE: Here’s a patch that does that same for aircrack-ng.

© 2006 – 2010, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

« Newer PostsOlder Posts »

Powered by WordPress