Security → Re: XKCD on Adobe Updaters

Linux. In our BSD-based KNOS OS, we use Linux emulation to provide Flash since Adobe has no interest in providing a BSD version of their players (they've now also stopped supporting Linux as well) which is how we discovered this curious little behavior. What Adobe does with their little trick also makes writing rootkits to do the same a piece of cake on Linux and its derivatives as well using Adobe's little trick of opening and then deleting a file handle and keeping ahold of a duplicate handle in the /proc stack.

You can read about how it works here:

http://blog.edwards-research.com/2012/03/grabbing-flash-files-from-cache/

http://askubuntu.com/questions/37267/how-can-i-access-flash-files-from-streaming-websites

http://n00bsys0p.wordpress.com/2011/02/10/how-to-download-flash-10-2-video-streams-in-linux/

In Windows, it's different since Windows supports "file locking." That is, the browser (or the Flash/Silverlight/etc. video-players to be specific) create the temporary file with a flag set that tells the OS to lock the file while it’s being used and immediately delete it when it’s released. As such, unlike other temp files, you cannot just copy it (because it’s locked) and when it’s unlocked, it’s gone.

http://superuser.com/questions/430791/determining-temporary-internet-file-type-chrome

I'm not sure about OSX, but I suspect they do the same stuff. In our OS however, we just let the Linux silliness occur in one of our sandbags and then ensure that the bag is emptied properly once Flash is done. We don't allow our OS to maintain proc or file handles without them being "alive" and visible.

Thanks for the details!

I have to admit since I'm in the BSD world, I don't follow Linux much anymore. I piped off that ship before I piped off Billyware, and wanted to avoid getting "too geeky" here. In KNOS, we have the BSD "Linuxulator" which emulates Linux in a similar manner to WINE for emulating Windows. We don't permit Linuxy things in our house for security reasons. Therefore, in what I'm explaining, I'm paraphrasing what I am told by folks who deal with Linux security in a similar manner to how we knew Winblows inside and out back in our BOClean days. In order to try to keep it simple, I used the term "handle" since many are familiar with that concept in Windows.

My UNDERSTANDING of the security issue rests in how Linux allows "pointers to file descriptors" to live after the actual file descriptor itself is gone, and since the pointer still points to a physical inode, it can hold the inode "privately" which means that any other process cannot fix the association and yet the kernel will not allow access to that inode pointer until that is released by the process which is holding that pointer open. What I'm told is that this method is how malware in Linux can for example "hold" an injected file while preventing any access to it whatsoever from outside of the rogue process. In other words, a behavior similar to a rootkit in being able to hold onto data on the disk privately.

However this works at the kernel level in Linux, the file descriptors no longer exist for sniffing, but the inode itself is somehow marked as not available. That's how analysts first tracking down a partcular piece of malware got the idea of looking further for why certain "free inodes" could neither be read nor written to. So that's where I got that little bit from.

As to how Adobe's "obfuscation" works, this little exercise explains it:

Adobe obfuscated the /tmp file method several updates ago. The flash
plugin still creates a /tmp file, but it immediately removes the file
link causing any "ls /tmp" calls to not see a file. You can still get
the file data through /proc.

$ ps -ef | grep plugin
# copy the PID of flash ($PID)
$ ls -l /proc/$PID/fd
# find the /tmp/flashXXXXXX file symlink ($FD)
$ cp -p /proc/$PID/fd/$FD /home/foo/flash.flv

I'm told that the above no longer works reliably as they've managed to find some even deeper levels of intrigue since in the latest Linux versions. But the chain of events I was describing are detailed a little further in these two links:

http://saylinux.net/story/009736/how-obtain-flash-videos-firefox-4

http://stackoverflow.com/questions/12337122/difference-between-creating-a-duplicate-file-descriptor-using-dup-and-creating

Suffice it to say that at least in our own BSD realm, none of this is allowed because we only emulate Linux. But the reason why we developed KNOS was because Windows had created too many hiding places, and I find it a bit disturbing that Linux is apparently creating catacombs too. And yes, I consider any method of hiding things a "dirty hack" ... they could have gone about coding it in a way that would allow the file(s) to remain visible and lock them properly, and cleaning up properly after they were done.