Finding multiple bugs!
Seriously, though, our most recent Digital Vaccine, DV7721, might as well have been called the iDV. Why? Every new filter released in that DV was for a bug in an Apple product.
Don't think that we're picking on Apple , though - this DV was our response to Apple's recently-released QuickTime and iTunes updates. It also contains a filter for a ZDI issue that was confirmed to have been fixed in the recent 10.5.7 update.
(Actually, I am going to digress and pick on Apple for a minute here. I feel like 10.5.7 was a bit of a fiasco. Well, that's not true. 10.5.7 was great. 10.5.6 was a fiasco and it took far too long to get 10.5.7 out.
Case in point: Raise your hand if you use FileVault. Raise your other hand if you also use Time Machine. Finally, raise your gripping hand if you use a Time Capsule. All three of these items are Apple products, right? They should just work. I understand that FileVault's interaction with Time Machine is suboptimal, but it does work after a fashion.
Well, it did work, after a fashion, until 10.5.6. 10.5.6 silently and completely broke FileVault home directory backups in that situation. If you had a Time Capsule and had FileVault-protected your home directory, your home directory just didn't get backed up anymore. No error messages, no popups, nothing. The FileVault images would get backed up if you logged out and logged in as another user and did a backup that way, but that sort of defeats the whole purpose.
Anyway, I didn't like having to use an alternative backup solution for the six months it took them to fix the issue. There were myriad other issues, some relatively important, that languished in an unfixed state for that length of time, but the backup one is the one that really irked me.)
I have a special place in my heart for this most recent DV. Don't get me wrong; all of our DVs are achievements, and proud we are of all of them, but this most recent DV contains two filters for vulnerabilities that I discovered.
The first vulnerability, TPTI-09-03, a vulnerability in iTunes, is more glamorous, and probably much more likely to be exploited, but the other one, TPTI-09-04, is, I think, more interesting. It is this vulnerability that I'm going to talk about in this blog post.
(Real quick: Props to Will Drewry, who also discovered the bug addressed in TPTI-09-03.)
The other bug is actually sort of obscure. It lies in the handling of xterm escape sequences in Apple's Terminal.app.
Terminal.app is Apple's default terminal emulator for Mac OS X. It is the way one would access the wonderful Unix underneath the shiny Cocoa exterior of Mac OS X.
To explain terminal emulation, though, let's take a step back down memory lane. Long ago, interaction with computers was not done by talking, or with mice, or by talking into mice, or even command lines. In The Beginning, computers were interacted with via a variety of archaic methods: physically rewiring the computer, submitting programs as punched holes in paper tape or cards, flipping switches on the computer's front panel...ah, those were the days!
However, by the time Unix came around (which was almost exactly 40 years ago), most systems had adopted some form of interactive, command-based interface. These commands were entered, and responses were delivered, via a separate piece of hardware known as a terminal. The first popular terminals were actually repurposed TeleType machines, communicating not with another teleprinter across the country, but a computer across the hall.
The original terminals were fairly lacking in features: they could advance the print head down the paper by one line, and, if you were lucky, could do it in less time than it took to print a character, so that nothing was lost. If you were extremely lucky, your terminal actually used the same character to produce a newline as the other terminals in your organization.
While this worked fine for a while, people soon got tired of having all of their mistakes printed on paper for the world to see and remember, so some smart people created a so-called "glass TTY". These glass TTYs were essentially a CRT attached to a keyboard. They emulated the older, paper-based TTYs. They had no real intelligence; all they could do was print characters as they were received from the other end, just like the paper TTYs. They just did it without the paper.
Eventually, though, more smart people created the "smart terminal" (named after themselves, presumably). Smart terminals abandoned the whole line-oriented approach for a screen-oriented approach. The remote end (the computer) could send special sequences of characters to these terminals, and these terminals would interpret them as instructions to move the cursor to a certain screen position, clear a line, scroll the screen up or down, and so on. This was, of course, awesome, because it allowed the development of all sorts of useful things, like Nethack, modal screen-oriented text editors, and text editors for people who haven't seen the obvious superiority of modal screen-oriented text editors.
Remember, though, that even the smart terminals contained no real intelligence - they just interpreted sequences of characters sent from the computer. Most of these characters were just printable characters - letters, numbers, punctuation, etc, or some small set of control codes (newline, bell, etc). The smart terminals needed a way to encode their special cursor-positioning codes into this data stream. The answer was the escape code.
In its purest sense, the term "escape code" or "escape sequence" is simply a collection of symbols in a stream of symbols that indicate that they should be interpreted differently from the normal interpretation mechanism. It eventually became convention that smart terminals were controlled by a set of escape sequences that consisted of an ASCII ESC character followed by a terminal-specific sequence of characters that instructed it to do something.
(ASCII included an escape character, ESC, precisely so that it could be extensible.)
What's important to note here is that these escape sequences are in-band. They are transmitted down the same channel as the data to be displayed. There isn't some sort of separate command channel or anything like that.
Fast forward to the present day. The conventions for interacting with Unix, Unix-like, and some other systems, haven't really changed. As far as they're concerned, outside of any windowing systems, you're still talking to them via a terminal connected by a serial line. Of course, the serial line is now a virtual serial line, and the terminal is now a window on the screen that emulates a terminal, but that's all just semantics.
With the advent of the X Window System, users had the wonderful ability to run multiple terminal emulators in multiple windows. The early xterm adopted the same set of escape sequences as the popular VT100 and Tektronix 4014 terminals. Eventually, though, xterm added additional escape sequences to take advantage of the abilities of a terminal emulator running in a window rather than on a fixed-size physical screen. Escape codes were added for useful things like resizing the window.
And now, after all that, we get to the first part of the bug. Apple's Terminal.app emulates (partially) an xterm. It responds to the control codes that result in resizing a window. For example, try this in a Terminal window:
Assuming your window wasn't already 600x400 pixels, it is now. That's because the sequence <ESC>[4 means "set the window size to the following numbers in pixels". That first part, the ASCII ESC character (octal 33) followed by an open-square bracket, is called the Command Sequence Introduction or CSI. It precedes most of the xterm-specific command sequences.
Well, the other day, I was thinking of things that might contain a security vulnerability. This is what I do when other people would be doing something actually useful. I thought, "y'know, I bet nobody has audited Terminal.app recently". I started thinking of things that might be vulnerable - one of the first things I thought of was changing the size of the terminal to some crazy size.
Well, a quick check by simply changing the terminal's size in its preferences inspector results in nothing interesting; you're prevented from setting a weird (negative or really huge) terminal size. Looks like, though, that prohibition applies only to setting the window size via the preferences inspector.
Terminal will gladly resize itself to any old size you specify via xterm's resize-window escape sequence. Even negative sizes or crazy huge sizes. The interesting part is, if you choose a specific couple of sizes or multiples thereof, you get crashes. Crashes with controllable memory corruption. Oops.
Apple fixed this in 10.5.7, sorta. It no longer crashes, but you can still get some interesting effects by doing something like this:
Try it. It's fun. (Note: On systems other than 10.5.7, that might crash Terminal, so don't have anything open that you want to stay that way.)
Okay, so, now the million-dollar question. So what? It's not like Terminal is a remote application or an application that routinely takes input from remote, potentially malicious parties, like Safari, at least, not without a ton of user interaction.
Oh, wait. It is. Terminal.app is Apple's default terminal emulator. It is registered as the default handler for "telnet://" URLs. That means that a web page containing a "telnet://" link, will automatically open Terminal. That newly-opened terminal will be running telnet, which will then automatically connect to whatever remote host it was told to connect to, on whatever port, and then start echoing the input it gets from that remote site to the terminal window. Input including escape sequences. Including malicious escape sequences.
This raises some interesting points. There are tons of applications that can be automatically opened just by visiting a web page. A lot of these applications probably aren't very high on any security team's list of applications to secure. After all, they're not being pounded on by remote data constantly, like Mail or Safari. Of course, when you start setting applications up to be opened from web pages, they become just as accessible as the web browser, but without the urgency of security auditing.
So, security teams the world over, remember: Any application that your remotely-accessible program can open is just as vulnerable and just as in need of auditing as the remotely-accessible program.