Fingerprints can change

With Apple's new fingerprint recognition, "Touch ID", for the iPhone, one of the problems they'll have to deal with is that your fingerprints can change. I experienced this when I was a kid by sticking my finger into a "router", a device that shaves off the corners of wood to round them.

This (picture on right) is what a router table looks like. You push the wood left-to-right, and the rotating bit in the center shaves the wood, to make rounded corners, or other corner shapes.

As I was pressing the wood against the fence, and moving it along, the router bit struck a knot in the wood, kicking it out. Because I was pressing forward at the time, I pushed my finger into the bit.

Finger tip prints are not fingerprints

You use a different part of your finger to touch the iPhone sensor than what you use to touch other things. Hold a glass in one hand, and hold your iPhone in the other with your thumb on your sensor. You'll notice that you are holding the glass with the flat of your thumb, but touching the phone with the tip. The two prints overlap slightly, or not at all.

That means while hackers may be able to lift your thumbprint from you holding other objects, or from other parts of the phone itself, they probably can't get the tip print needed to do bad things on your iPhone.

This means the fingerprint databases held by the NSA, FBI, and border security are largely useless at unlocking your phone: they don't cover the same parts of your fingers. 

I point this out in regards to the latest iPhone 5S release with "Touch ID" sensor that reads fingerprints instead of requiring you to type in passwords. We cybersec hackes will be discussing how to break this in the near future, so I thought I'd be the first to make this observation.

Smart or Dumb: The OSX update saga

Have you ever logged into OSX at gotten a message about needing updates although you are sure you have applied them already? How about a message saying that you need to accept certain packages like iPhoto in the update manager but when you try you are told they have been purchased with another account and you need to login with that one to install them? Looking at the Apple OSX support forums across a number of sites I can tell you don't bother answering, I know it is a rhetorical question. These errors happen to a lot of people and all the time. Eventually some other forum user will suggest some bit of command line trickery that has nothing to do with the problem and the errors go away.

Apple's profits: 70% tax rate

Congress is grilling Apple on it's tax avoidance. The problem isn't with Apple, but with Congress rapacious theft of as much money as it can get its hands on.

The United States is unusual in two respects.

The first is that its corporate tax rate is 40% compared to 24% that is average in the world, and the 0% that economists think it should be. The reason economists believe this is because corporate taxes are double taxation: taxed once when the company earns the money, then a second time when dividends are paid to the stock holder.

The second problem is that, unlike other countries, the United States taxes foreign earnings. This causes another example of double taxation: once in the country where Apple earned the money, and then once again in the United States.

Combined, this means triple taxation. With the current max dividen tax rate of 39.4%, the corporate tax of 40%, and the average foreign tax of 24%, the total tax bill becomes 72%.

In other words, for every dollar Apple earns in profits, 72 cents goes to the taxman and 28 cents goes to the stock holder.

Here is a great CATO article on the subject.

Ruby on OSX 10.8 followup

After a ton of comments privately about using Homebrew instead of Macports I decided to try it out. I did a clean install on my Macbook Pro and here are the steps I followed.

1. Install Xcode 4.6 and command line tools.
2. Open terminal and run command:
\curl -L https://get.rvm.io | bash -s head --ruby

3. Enjoy ruby.

That is much easier. So much easier! Apparently rvm head will install Homebrew, all the required dependencies, and build a working copy of ruby. The #rvm channel on freenode helped me with this. I am now upset at the time I wasted trying to get the other way to work.

This may be old news to some but I wanted to throw this up because I spent a ton of time Googling and did not find a good solution, I hope this helps others. Now I am going to build the ultimate post reinstall script for setting up OSX for security people!

dm1z and MacBook Air: a quick pre-review

Since this came up on Twitter, I thought I'd mention two recent purchases: the HP dm1z $400 netbook and the Apple MacBook Air $1000 thing.

Heres how we do that voodoo that we do (iPhone Hacking)

The Internet was buzzing a few weeks ago with Charlie Miller’s iPhone SMS exploit. Reading the vague details available in different news stories it reminded me of some work I had done many months ago that involved a USRP, OpenBTS, and several different phones. The results were pretty spectacular for the same reason Wifi fuzzing found tons of problems: when a developer assumes that there is strict control over both ends of a transaction they don’t do as much error checking as they should. After all, since it's only your code (or other code from friendly people) sending data, then the code receiving data doesn't have to check input.

LORCON helped disprove that idea with Wifi. The USRP+OpenBTS combo is doing the same for GSM based handsets.

The crinkly bits is that to find bugs with OpenBTS, you have to trick a cellphone into connecting your hostile base-station rather than a commercial cellphone tower. This is why I found Charlie Miller's and Collin Mulliner's research interesting: they claim they discovered a way to inject SMS locally for testing that wouldn’t be seen by your provider, making fuzz testing easier. I have seen local SMS injection exploits before but never for the iPhone, so I thought i’d spend a day poking around and see what I could come up with. The rest of the blog post is an accounting of how I spent the time searching for this vuln, how I duplicated a vuln that fits their description, and what to do next.

The first thing I needed was an iPhone. I have one I use everyday, but I'm afraid of bricking it. Instead I dug up an old first-gen iPhone. I assumed that executing the fuzzing code mentioned in the abstract would require jailbreaking the phone since it seems impossible to accomplish that task within the iPhone SDK. I was delightfully surprised to find that using redsn0w made jailbreaking the 3.0 firmware a snap. I installed some basic apps I thought I would need, including the iPhone toolchain (you can compile code directly on the iPhone), ruby, OpenSSH, and the mobile terminal. After looking through the Cydia repository I saw there were some apps that allowed for the sending and receiving of SMS messages. These seemed to be a great place to start. The first example I found is called "aSMS", which has a Google Code project: http://code.google.com/p/iphone-sms/

The aSMS app is a bit odd, the front-end is in the browser, and the backend is a built-in webserver on the iPhone. I spent a few minutes going through the source and found it used what appears to be a baseband debug trick to send messages. The word "baseband" is one way of referring to the separate CPU and operating-system that runs the cellular radio. "Baseband hacking" is were do things like unlocking a mobile phone so it can run on any carrier, and enable features a carrier doesn't want you to use (like tethering or MMS). More specifically the trick uses the device /dev/tty.debug. Googling for "tty.debug" and iPhone led me to another Google Code site and a tool called sendmodem: http://code.google.com/p/iphone-elite/downloads/list

Sendmodem came with a makefile, a .c source file, and a compiled binary. As a side note: this is the best possible situation for a person like myself. If I can’t find the answers I want in the source I can reverse the binary to look at additional items that get added at build time. If that doesn’t yield the answers I am looking for, I can compile my own version and debug it. Something I found funny was the note of the sendmodem wiki that states this code come from the aSMS app I started out with. The wiki also sent me here (http://www.developershome.com/sms/howToSendSMSFromPC.asp) which provided information on how to send a SMS using AT commands and a cellular modem. And finally the wiki provided me a list of undocumented AT commands (http://code.google.com/p/iphone-elite/wiki/UndocumentedATcommands)

With all this information, I started poking around my iPhone. The first thing I wanted to do is see if all the information I had been reading about was still around in the newest v3.0 OS my test phone is running. Nothing would be worse than spending hours on an assumption only to find that the feature you need was removed a few revisions ago. The first thing I tried was using the tty.debug trick to send a text message. I wrote a small ruby script for that:



It worked. I then tried to send a test message to my own number. I figured this could be the simplest way to achieve the functionality for fuzzing. However, this didn't work so well. Every time I sent a text message to the same number it originated from the baseband would disconnect and no longer receive text messages until the device get a reboot.

After a little over two hours into this exercise, I had a lot of information but a lot more epic fail. I'm the king of Thomas Edison's quote of "I have not failed, I've just found 10,000 ways that won't work". Feeling the path I was on was fruitless, I tried another direction: I looked through the filesystem for anything called "sms". Although I got a lot of hits, but the most interesting thing is "sms.db" in "/private/var/mobile/Library/SMS". Using the "file" command I discovered the database is a SQLite3 database. Since that is a fairly well documented database, and there are tons of tools to view the contents, I copied it off the phone and to my MacBook. The used "SQLite Manager", a Firefox plugin which can be found here: https://addons.mozilla.org/en-US/firefox/addon/5817


The sms.db overview and structure as seen in SQLite Manager.


The result of the SQL query "SELECT * FROM message"

After examining the different tables and data it seems that this is where SMS messages are stored to be later retrieved for viewing and such. Using this as a ending point I can work my way backwards to where the messages come from.

Next I enabled syslog debugging, so I can information while sending a SMS message to the device, this should help identify processes that are involved in receiving and processing messages.

The last message in the log reads "CommCenter[30]: removing received message 2147483653".

CommCenter is involved in receiving and processing SMS messages to some degree. Searching the disk for CommCenter gives a lot of results but one catches my eye: /private/var/CommCenter/spool. The word "spool" looks similar to the Unix "mailspool", and is likely the place to store files that are being sent or received by the device. The spool directory has two subdirectories MobileOrginated and MobileTerminated. Both directories were empty, but if the Unix style spool architecture is being used, temp files will be created as messages are sent and received and removed when no longer needed. I wrote a quick and dirty Ruby script that will monitor the directory and copy any files it finds, even if they live for only a second.


Simple Ruby script to check and see if Directory is empty, if not copy the contents to /tmp/

I then run the script and send a SMS to the target phone. I get the expected output that a file has been created and moved to /tmp. The file is named r.sms.2147483652


The contents of the /private/var/CommCenter/spool/MobileTerminated direcotry.

Examining the contents its pretty easy to see that this is the incoming message I sent from another from. I ha the phone number that the message was sent from, the message, and some unprintable characters. I then copied this file off the iphone to my macbook and used hexdump to view the message to see what the unprintable characters are.


The text message in hexdump.

Doing the same for the MobileOriginated directory got a file called p.sms.58. The structure seems almost the same with the destination phone number and the message surrounded by a few unprintable characters. The message I sent was "What up Homey!"


The p.sms.58 message in hexdump.

I now know an intermediary point in the SMS delivery process. I attempted to create my own file in the MobileTerminated directory to see if it would be delivered as an SMS message, but no luck. Something is copying the files there then notifying CommCenter there are messages to be processed. The next step was to analyze the CommCenter binary and find any clues on how it operates and where the signal to process messages comes from.

I created a tar file of the iPhone filesystem with the command "tar czvf /tmp/fs.tgz /" and let it run. Although this is not the most efficient way to do this (a copy of the tar file is going to end up in the tar file) is it pretty fast. I then used WinSCP to copy the file down to a VMWare Fusion image of Windows XP running on my Macbook. My Windows image has most of my reverse engineering tools, including IDA Pro and HexWorksop. It also has the Windows version of Ruby installed because Ruby is pretty useful for reverse engineering binaries. The fs.tgz file is unzipped with WinRAR and the search for CommCenter begins. CommCenter is located in /System/Library/PrivateFrameworks/CoreTelephony.framework/Support

I loaded the file, selected the CPU (ARM), and configured my analyze options. Although IDA Pro is the best tool for this type of work it sometimes doesn't get everything, so I had to go through the disassembled code and fix a few things. The problems were pretty forward and easily fixed. An example problem was this:


This will become more readable like this:


After a few minutes of analysis it seems clear that the baseband module receives the message, and then CommCenter reads it using an AT command. At this point we can break testing into two different parts: CommCenter and MobileSMS.

CommCenter Testing: Fuzz From SMS.db to MobileSMS UI

MobileSMS is the application that handles reading the files from the database and displaying them. Testing MobileSMS is as simple as writing malformed messages to sms.db and then running the SMS application. Well, it would be simple if it wasn't for the database triggers. Trying just to insert a message ends with an error. The is answer is to delete the triggers then recreate them. Here is how to do it in SQL. This statment can be entered into the SQLite Manager:

drop trigger insert_unread_message;
drop trigger mark_message_unread;
drop trigger mark_message_read;
drop trigger delete_message;
CREATE TRIGGER insert_unread_message AFTER INSERT ON message WHEN NOT new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) + 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER mark_message_unread AFTER UPDATE ON message WHEN old.flags = 2 AND NOT new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) + 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER mark_message_read AFTER UPDATE ON message WHEN NOT old.flags = 2 AND new.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = new.group_id) - 1 WHERE ROWID = new.group_id; END;
CREATE TRIGGER delete_message AFTER DELETE ON message WHEN NOT old.flags = 2 BEGIN UPDATE msg_group SET unread_count = (SELECT unread_count FROM msg_group WHERE ROWID = old.group_id) - 1 WHERE ROWID = old.group_id; END;

Once that is done a simple insert statement should work:
INSERT INTO "main"."message" ("ROWID","address","date","text","flags","replace","svc_center","group_id","association_id","height","UIFlags","version","subject","country","headers","recipients","read") VALUES ('4','111111111111111111111111111111111111111111111111111111111111111','999999999999999','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','38','0',NULL,'3','0','0','9882987','0','hjdfbvljhvbzjldhvbjlvbjdbvjhdbvjhdvhjdg','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa','0')

You can figure out the columns and what value they are expecting from looking at the table description. To understand what they mean I found a URL in the SendSMS code that explains SMS fields and formatting: http://www.dreamfabric.com/sms/. This information is useful if you want to make a fuzzer more accurate and directed. One problem is that the information does not exactly match up with he database format so it requires some experimentation to find out what each field means. The results follow:

Field Name	Input expected	Description
ROWID	INT	The datbase row, used as a key
address	Text	The phone number in the From field
date	INT	The time the message was recieved in Unix time
text	Text	The message body
flags	INT	Show if a message was sent or received. 2 is for sent and 3 is for received
replace	INT	Shows is a message is replacing a current message, like is a newer version is received.
svc_center	Text
group_id	INT	Used by the SMS UI to group messages. If this is set to a id that is not also in the msg_group table, the message will not be displayed.
association_id	INT
height	INT
UIFlags	INT	If sent to 1 the UI will act as if a URL is present.
version	INT
subject	Text
country	Text	Country Code. The United States is set to us
headers	Blob
recipients	Blob
read	INT	Shows if message has been read or not. 0 means it is unread, 1 means it has been read

This information was collected by a trial an error process of sending and receiving messages then duplicating them with different options. If that didn't work I took the SMS message apart and traced it through CommCenter to its insertion in the database. If the field is still blank I can't find anywhere it is actually used and may be used for MMS which I do not have enabled because I am on ATT. Below are some pics of my trial and error process.


The SQLite view of the test messages.


What the testing actually looks like on the iPhone. You might notice the red exclmation points next to the final two messages. This means the SMS was unable to send and it may happen after mucking arounf witht he database enough. Luckily you can just delete the database, kill -HUP the Springboard process, then restart the MobileSMS application. This will recreate a virgin database for you. The failed messages look like this in syslog:

Jul 23 18:24:49 daveTestIphone2g MobileSMS[85]: no URLs for message: Incoming test
Jul 23 18:25:07 daveTestIphone2g com.apple.SpringBoard[26]: told to send sms 18
Jul 23 18:25:07 daveTestIphone2g CommCenter[30]: queuing sms message with id 18
Jul 23 18:25:16 daveTestIphone2g com.apple.SpringBoard[26]: internalID: [18]
Jul 23 18:25:16 daveTestIphone2g com.apple.SpringBoard[26]: notifying clients of event: 3 (recordID: 18)
Jul 23 18:25:16 daveTestIphone2g SpringBoard[26]: send error: < 0x2483d0="">
Jul 23 18:25:16 daveTestIphone2g MobileSMS[85]: send error: < 0x191ad0="">
Jul 23 18:25:16 daveTestIphone2g MobileSMS[85]: _SMSMessageSendError

As far as a fuzzer actually goes using Ruby and the SQLite gem means that a fuzzer could be whipped up in a few minutes. Knowing the field input types and the rules around what gets processed vs what doesn't helps speed this process along. A simple script will just open the database, insert several rows, close the database the kill -HUP the SpringBoard process. The HUP seems to help the UI close then reopen the database and process your new messages.

Things to try involve long strings, unusually high numbers, and setting values that aren't normally set. Below is an example of a crash received after processing a database full of fuzzed messages. The offsets have been removed so we are not accused of releasing 0-day, how ever if you follow the above steps it is pretty easy to duplicate.



CommCenter: Fuzz From Baseband to SMS.db

Back to testing the code that recieves the message and puts it in SMS.db. Looking back at the sendsms tool it seems the best way is through the use of "/dev/tty.debug". Since the sendsms command to my own address doesn't work lets look at other ways to do it. http://rednaxela.net/pdu.php helps you by allowing you to put put in a SMS PDU and it will tell you what it means or you can create your own. A sample SMS PDU is needed. Using minicom on the iphone I connect to the baseband and issue a few commands that give me a binary SMS PDU.

I need my SMSC number and since it is not stored in the SMS.db file typing a debug code on the keypad will show you. I type *#5005*7672# Here is what it looks like:


Next I went back to the Rednaxela site and build a test mesage:


Taking a tour of CommCenter in IDA I trace some code from the function that begins processing spooled messages in MobileTerminated, the the trigger for it.

The function that process SMS messages:


And the command that beings the processing is +CMT:


Starting Minicom I sent the message and play around with various AT commands.


It seems that sending a message with AT+CMGS=length of message produces the desired result. Creation of a test message is easy and it reads "Testing Local Testing". After hitting CTRL-Z after pasting in the PDU I got this on the phone:


Referring back to the website earlier that describes a SMS PDU and all the different options allows for quick fuzzer creation. You can write a small Ruby script to take your fuzzzer output and write it to /dev/tty.debug and monitor the results. This path finds as many bug as the other and they should be tracked down and verified.

In Closing

This paper shows the extent that researchers can follow breadcrumbs to reproduce a work. That's the risk of partial disclosure: a simple description, such as "SMS crash on an iPhone" can give researchers enough hints to reproduce the work.

I haven't figured how how to successfully exploit the crashes I've found. The SMS network only allow 160 characters through their networks. It might take a multistage process (send many SMS messages with shellcode, then a final message that overflows a buffer to run it). Or, it might be something simple to overwrite a few bytes to unlock a phone.

Ode to 50cent

I was recently on a plane for a LONG, LONG time. For me this is roughly equivalent to putting a cat in a box and dangling it over water. I get bored easy and after watching all the television shows I had brought with me I decided to play with IDA and any unsuspecting binaries from my laptop that I randomly selected. While doing this I noticed iTunes kept crashing, predictably and reliably in the same place. I decided to use gdb to see what the hubbub was all about. However I got dissed and iTunes would not allow itself to be debugged.



This would not do. Not knowing anything about the anti-debugging capabilities of iTunes I decided the best way (and the laziest way) for a programmer to try and keep me from debugging is ptrace. I set a breakpoint on ptrace and tried it again. I got a nibble. I typed return, and then let iTunes continue on its way. It worked somewhat: it would continue but I was prompted over and over again to complete the same task and if I deleted the breakpoint iTunes would exit. I decided to modify ptrace to return immediately. I did so with the following command:

set *(int)ptrace = 0xc3


0xc3 translated to ret. After I did this I deleted the breakpoint and let iTunes go about its normal activity, or as 50cent would say, “sit back and let the money pile up.”


B00m, we have a crash.

Now I can examine the information from the crash and work on how exploitable the problem is. The exploitability is a post for another day; I just thought some folks could use a nifty trick if they found themselves in a jam.


(This post was written to 50cents “How to rob.” Also I typed some commands in gdb that produced errors becasue my regular alias file was not loaded.)

The latest low blow for Apple

ZDNet covered a study done by French researchers at CNRS claiming that Mac Pros manufactured before 2008 contain at least one carcinogenic chemical, Benzene. The researcher making this claim detected a suspicious odor upon unboxing, and later found 7 compounds in the machine that can be hazardous to humans. O'Grady at ZDNet said that the odor was a known problem backed up by posts from other users on message boards. The article has this great quote:

This problem is as bad for Apple as the contaminated milk problem for China, and it may very well be the first scandal of this kind in the computer industry.

(Why are there so many great quotes and analogies about Apple?) The evidence on both sides is pretty convincing. One one side there's a researcher who's own lab colleuege is calling his science into question, (comments), and on the other side is a typically silent Apple with no comment. It's implied that they are aware of the problem, and are doing everything to fix it quickly, but also that they don't think that the problem is really a problem. (i.e. They know the computer smells funny, but aren't going to say it gives you blood cancer.) I, for one, would like to believe that.

A recall would probably be slightly irritating for Apple. (Making the sure bet assumption that they'll never prove Mac Pros cause cancer.) Apple had to recall 1.8million notebook batteries in 2006 due to a overheating battery. They were barely effected, but the manufacturer Sony took a several point hit. Will Apple be able to shift the blame this time as well?

EDIT: There is a semi-update on Apple's nonposition on this.
Apparently they're "looking into it" even though they don't believe it's true. Because that's what major corporations do when one person says something that everyone else basically thinks is nonsense... they launch a research campaign.

Oh the zealots will be on the warpath...

http://www.theregister.co.uk/2008/08/13/phishers_attack_mac_faithful/

I can't wait to see what excuses the Mac zealots come up with for this or the horrible showing the iPhone had at Defcon regarding the Wall of Sheep.

New Firmware

Thanks to lifehacker, http://lifehacker.com/398280/iphone-20-software-update-unofficially-available, My iphone is now running te 2.0 firmware.

Apple malware

Macs only seem safer that other OSes. In reality they are just as risky. Because of this, I pay attention to any report of Mac based malware and exploits. Last week two Mac security vendors (I didn’t know the market was large enough for one) announced that they had discovered malware in the wild that took advantage of a recently discovered flaw that allows the an Applescript to run as root because of the permissions of the Apple Desktop Agent. In the Windows world it is common to talk about a vulnerability going from PoC to malware in a few hours or days, but this is the first time I can think of it happening on a Mac. The Mac flaw was made public on Slashdot on June 18th and the Macscan advisory is on June 19th. You can come to two different conclusions and neither is good for Mac users.

1. You could conclude that malware authors are starting to pay more attention to Macs and quickly wrote malware to take advantage of the flaw. This means that as more vulnerabilities appear so will more malware. This is not good for a population of people that have been repeatedly told they do not have security problems.

2. You could conclude that this vulnerability is publicly known because the new Trojan uses it to install itself. This would mean that malware authors are finding and using 0day to spend their wares. This also is not good for a population of people that have been repeatedly told they do not have security problems.

Either way the Apple security problem is growing.

Ruby vulns: its been 3 years in the making

After a busy weekend, I come back to the magic of RSS to find multiple security holes in Ruby. I had heard about this last week but could not find any details. It seems that more information comes in the form of an Apple Security team member, Drew Yao, who made the discoveries. You can read more about it at Matasano or from ruby-lang.

These finds are very cool and I have always been interested in bugs in interpreted languages mostly because people think they are a “more secure” standard by some folks because they think the memory corruption angle is no longer an issues.

The first time I saw anybody publicly talk about this problem and a potential attack was Blackhat Tokyo by Dom Brezinski. Actually when I say “I saw the talk” I mean I was sitting next to him in the speaker room discussing the problem afterward because I was giving a talk opposite of him on how to break security tools. The previous statement is to head off the trolls who will undoubtedly comment about my lack of actually seeing the talk because I was scheduled at the same time.

Apple still not playing nice with researchers...

http://www.theregister.co.uk/2008/05/22/unpatched_apple_bug_flap/

Update on Apple and QuickTime

I just read at the Infosec Blog that a new version of QuickTime has been released that contain fixes that should make QuickTime harder to exploit on Vista. I say should because although it is a good start Apple did not completely close the loop. The reason ASLR is important to thwarting hackers is that the memory space of an application is randomized, or as the king would say, they are all shook up. Since most buffer overflows rely on knowing where a piece of code or data is in memory, the randomization can turn a remotely exploitable bug into nothing more than a Denial-of-Service. Although targeted attacks against individuals may still be possible, widespread QuickTime exploits will be much harder to write.

Not to signal doom and gloom but there is a problem or two. The main problem with implementing ASLR is that is really is all or nothing venture. If you have even one static shared library you open yourself to compromise. Below are screenshots of the new QuickTime from a filesystem and a process point of view using LookingGlass. Although most of the files are now marked as ASLR enabled there are still a few binaries that are not and could still provide an attacker a static location to utilize.

Don’t let these few oversights detract you from the huge stride forward Apple is making Vista users safer. It is good to see Apple embracing these security enhancements and I encourage other vendors, like Adobe, to follow their lead. I also hope that Apple extends these improvements to the other products offered to Windows users.

QuickTime File system scan withLookingGlass.

QuickTime Process scan with LookingGlass.

Queens wear brown...

The Vista laptop also went down, the fault of Abode. The irony of Adobe being at fault is only compounded by the LookingGlass vendor of the week last week being Adobe. No NX, No ASLR, unsafe libraries, no cookie Adobe.


http://www.cnet.com/8301-13509_1-9906502-20.html

Only the Mac faithful could take something like a Macbook being hacked and turn it into a commerical for Apple products. It seems as if the Macalope is stumping for a job as Apple's Chief Security Officer or as Obama's running mate, I can't decide which.

"Plus, you hack it, you keep it. So, sure, everyone's trying to hack the Air."

He seems to imply that the only reason people were hacking Macs were they get to keep them. Since not everyone can live without the faux sexiness that is Apple, of course someone will find a way to go home with that hardware. He also goes on to explain the only reason "security researchers" are paying attention to Mac is that they are cool and we are not.

I have a different theory: it was the easiest. With Vista and Linux correctly implementing technologies Apple botched like ASLR it is the naturally easiest target. If you want an analogy, it is kind of like the slow Antelope that has been separated from the herd by predators.

We all know what happens to that ailing animal.

Safari and Apple get Owned...Again...

Last week Apple released a huge security update, likely because 7 days later CanSecWest would be hosting its PWN2OWN contest. I wanted to write a blog post then and mention something about the best way to force Apple into releasing patches would be to announce an upcoming exploitation of Apples. It's not just Cansec, but the same thing happened when I announced I'd be publishing the disputed WiFi vulns at Toorcon, they quickly patched the vulns they denied existed. However, I decided to wait on that blog post.

Later in the week I saw Safari update debacle. I wanted to write a blog post about the underhanded padding of their marketshare, and note that Apple just made millions of Windows users less secure now by adding additional insecure code to their machines. However, I decided to wait on that blog post, too.

I decided to wait on writing both these posts because I know that even with the updates that Apple has released for Safari there are still tons of flaws in it that are exploitable and someone would leverage one to win the PWN2OWN contest and walk home with a Macbook Air.

Dave Aitel just reported on DailyDave that Charles Miller won the Macbook Air using a Safari exploit. I would like to note that out of the three machines (OSX, Linux, Vista) OSX was the first to fall. I hope this puts to rest the myth that OSX is more secure but I am sure the zealots will have a million reasons why this is a fixed or rigged contest. The only question I have remaining is who is going to be the first to file a class action lawsuit against Apple on behalf of users who were tricked into installing Safari and are now at risk of compromise? I am not advocating someone do that, I am not fan of needless litigation, but I can already picture the commercials the ambulance chasing lawyers could use.

"Were you tricked into installing Safari by Apple? Have you had any personal data compromised? Call the law firm of Dewey, Cheatem, and Howe!"

The other interesting thing about the updates is something I like to call the "window of owning". I advise our clients on this: Apple bundles open-source, but patches it late. It takes them weeks to as long as a year to patch their version of the code after it was patched in open-source. It's fairly straightforward to keep track of the open-source (and other 3rd party) code that Apple uses it, and when a vulnerability is announced for the open-source version, write exploits for the Mac version.

This "window of owning" is one reason that the update last week was so large. Apple security dug deep and fixed a lot of vulnerabilities that they would normally not bother with in a futile attempt to get OSX through the PWN2OWN contest unscratched.

UPDATE: More info at Security Focus.

UPDATE 2: Some people don't know the screenshot above is from our LookingGlass tool. I added it to show how many unsafe functions are used in Safari as well as the lack of ASLR or NX support. This means that I would wager that a vulnerability in the OSX version of Safari would also work on XP/Vista with a high success rate since Apple does not employ any of the available features to mitigate an attack.

New Apple Quicktime Problem – UPDATE

On Thursday an advisory was released to several security research mailing lists with an advisory for an unpatched flaw in Quicktime as well as a simple Proof-Of-Concept(PoC). Over the weekend, that simple PoC morphed into a much more robust attack tool. The current PoC, which is really a weaponized attack tool in sheep’s clothing, will cause memory corruption in both Vista and OSX 10.5.

Quicktime has had a rough time recently with a number of flaws putting both Windows and OSX users at risk. You can’t fault them for having flaws in their software, everybody does. The problem I have with Apple is that these attacks would not be exploitable if they took advantage of advanced security features in Vista. This exploit requires an attacker to know a static offset in the process space that they can use to their advantage. Taking advantage of ASLR in Vista would mitigate this risk and keep millions of Windows users safe. In the update form the last problem, ASLR was not enabled and as I have previously shown it is nothing more than changing a bit a QA cycle.

Due to Apples lack of adoption of these features or a secure development cycle, I have recommended to our customers that all Apple software should be removed from Windows machines. That is Quicktime, iTunes, and Safari.

What the exploit looks like running with default options.

The OSX 10.5 crash.

The WinDBbg output on Vista.

New Quicktime Flaw, this is not Deja Vu

No really. Its ANOTHER QuickTime flaw. It also involves RTSP. It was posted to Full Disclosure on Thursday afternoon. We have verified a crash on the latest OSX and are currently researching if it can lead to remote code execution and which platforms are affected.



The advisory is here:

http://aluigi.altervista.org/adv/quicktimebof-adv.txt

New Apple Problem

http://www.securityfocus.com/archive/1/485237/30/0/threaded

You know, the one thing you don't want to have when everybody needs to updated due to a critical problem is a vuln in the update process.