Tag Archives: patches

Reversing Prince Harming’s kiss of death

The suspend/resume vulnerability disclosed a few weeks ago (named Prince Harming by Katie Moussouris) turned out to be a zero day. While (I believe) its real world impact is small, it is nonetheless a critical vulnerability and (another) spectacular failure from Apple. It must be noticed that firmware issues are not Apple exclusive. For example, Gigabyte ships their UEFI with the flash always unlocked and other vendors also suffer from all kinds of firmware vulnerabilities.

As I wrote in the original post, I found the vulnerability a couple of months ago while researching different ways to reset a Mac firmware password. At the time, I did not research the source of the bug due to other higher priority tasks. One of the reasons for its full disclosure was the assumption that Apple knew about this problem since newer machines were not vulnerable. So the main question after the media storm was if my assumption was wrong or not and what was really happening inside Apple’s EFI.

The bug is definitely not related to a hardware failure and can be fixed with a (simple) firmware update. The initial assumptions pointing to some kind of S3 boot script failure were correct.
Apparently, Apple did not follow Intel’s recommendation and failed to lock the flash protections (and also SMRR registers) after the S3 suspend cycle. The necessary information is not saved, so the locks will not be restored when the machine wakes up from sleep.

This also allows finding which Mac models are vulnerable to this bug.
All machines based on Ivy Bridge, Sandy Bridge (and maybe older) platforms are vulnerable. This includes the newest Mac Pro since its Xeon E5 CPU is still based on Ivy Bridge platform. All machines based on Haswell or newer platforms are not vulnerable.

Now let’s jump to the technical part and understand why the bug occurs. I am also going to show you how to build a temporary fix.
Continue reading

How to compile gdb in Mountain Lion (updated)

This is an up-to-date version of the old original post about recompiling gdb and other open source packages provided by opensource.apple.com. I’m doing it mostly because code signing is now mandatory for gdb and there’s a stupid old bug that Apple still didn’t fixed since Snow Leopard. I forgot about it on my latest reinstall and lost an afternoon :-). This way you and me will not make the same mistake.

You should have XCode installed. Follow these steps:

1) Download darwinbuild from their SVN repository.
1.1) Since Snow Leopard there is a svn client by default so no need to download.
1.2) Follow the instructions on how to download,compile and install darwinbuild here. Use the guide for Snow Leopard/Lion version, it’s compatible with Mountain Lion.

2) Compile and install darwinbuild:

$ make ; sudo make install

3) Create the DMG file and initialize darwinbuild environment (you should use at least 2 gigabytes):

The plists and build numbers are available at http://svn.macosforge.org/repository/darwinbuild/trunk/plists/. Use build number 12A269 (it’s for 10.8.0 but works ok for all others).

$ hdiutil create -size 2G -type UDIF -fs HFSX -volname Builds -uid 0 -gid 0 -attach Builds.dmg
$ sudo sh
# vsdbutil -a /Volumes/Builds
# cd /Volumes/Builds
# mkdir Build12A269
# cd Build12A269
# darwinbuild -init 12A269 (you need Internet connection)
# darwinxref edit

In darwinxref edit you need to add the gdb package to the configuration. Go to the projects section and add the following:

gdb = {
version = 1822;

Default editor is VI. Save and quit. If you have a problem with an invalid property list, use the same tab alignment as the other entries. That should fix it.

4) Clone the gdb-ng repo from github if you want my patches included (you probably do!). Else skip to step 5) (darwinbuild will download the package from Apple opensource repo).

# cd /Volumes/Builds/Build12A269/Sources
# git clone git://github.com/gdbinit/gdb-ng.git
# cd gdb-ng
# bash pack.sh
# mv gdb-1822.tar.gz .. (check version in case it changes)
# cd /Volumes/Builds/Build12A269

5) Compile gdb.

# darwinbuild -nochroot gdb

The -nosource option has been added to recent darwinbuild versions. This option will allow you to patch directly into BuildRoot/SourceCache/.
The first time you shouldn’t use this option so darwinbuild will download gdb package. After that you can use it if you want to patch directly gdb source files (that’s what I do with my gdb patches). It’s much easier and faster than having to patch and compress the whole gdb source. After you patch, you just issue “darwinbuild -nochroot -nosource gdb” and this will not unpack the original source but instead use whatever is at SourceCache.

Wait for the compilation to finish…

Go to Roots/gdb/gdb-1822.root*/usr/libexec/gdb. You should have a gdb-i386-apple-darwin. Backup the original and copy this one over.

# cp /usr/libexec/gdb/gdb-i386-apple-darwin /usr/libexec/gdb/gdb-i386-apple-darwin.orig
# cp gdb-i386-apple-darwin /usr/libexec/gdb/

The latest step is to codesign the binary. This is because taskgated default configuration has changed and it’s not anymore sufficient to have the binary suid to procmod group. It must have entitlements and be codesigned. The process is not just creating a self-signed certificate and codesign the binary with it. There is an old bug since Snow Leopard that complicates it a little bit. Follow this guide from LLDB code signing document. You can either code sign the binary you copied above to /usr/libexec/gdb or sign it at the Roots folder and copy the signed version.

Launch gdb and see if it works. It should ask you for your password the first time (after each reboot). If everything is ok you should be able to attach to or run the target process.

Now you can enjoy your next afternoon in case you want/have to compile gdb. You might also want to download and install gdbinit to improve gdb’s output and available commands.


Update to gdb patches – fix for a “new” bug

I was messing around with SoftwarePassport and Amit Singh’s tiny executable to find out why gdb doesn’t breakpoint in those two executables. I thought it was due to incomplete headers, but gdb can’t also breakpoint into nicertiny, which has the segment/section added (otool/otx SoftwarePassport problems can be fixed by manually adding the missing section – there is enough padding space in the header to do that so its developers might want to fix that :-)).

Anyway, I decided to use the int3 trick to see if gdb was able to breakpoint and it worked. But then I wanted to manually fix the code – restore the original byte and point EIP to the correct address – and gdb didn’t allowed me. You get a “Value being assigned to is no longer active.” error message. Web searching for the problem, and there is a small patch at https://bugzilla.redhat.com/attachment.cgi?id=313103&action=diff. I tried it and it works! The problem isn’t exclusive with these two binaries but happens if you stop at the beginning of a function and gdb is missing stack frame information. So it’s a very useful fix 🙂
I have also included in this patch the fix for LIBICONV problem, as described here. If you don’t want to compile gdb yourself, I’m including the (fat) binary, compiled in Snow Leopard, 32/64 bits.


SHA256(all_patches_v0.2.patch.gz)= e9e113b583f6eeea47025fce612028ca76b63386cc35d6fcda5bb7c9a705814f

SHA256(gdb-i386-apple-darwin.gz)= 5ed41b093cd451b55bf35b6f103a9879c1e224f4721647c82757f8aee21293fb