Archive for the ‘security’ Category

NY Times Tech Talk – Interview with iPhone Pwn2Own Winner

April 11, 2010

I realize this is a week late, but I’ve been catching up on podcasts this weekend and I listened to this one while running today. The New York Times Tech Talk podcast for 1 April 2010 includes an interview (at 19:30) with Ralf Philipp Weinmann from the University of Luxembourg who, with Vincenzo Iozzo of Zynamics, pwned an Apple iPhone in 20 seconds. Weinmann explains that the exploit wouldn’t necessarily require social networking even though the iPhone at CanSecWest was given a URL to a site containing their exploit. Once the device was pwned, all account information was available as it’s stored in one file — all text messages, e-mails, contacts, photos, etc.

Weinmann couldn’t provide much detail due to Tipping Point’s non-disclosure requirement for pwn2own. Charlie Miller, who’s won pwn2own before targeting Macs, predicted iPhone would fall quickly. Miller confirmed something Weinmann said in the podcast, namely that putting together the payload is the difficult part. Miller explained why it’s more difficult to pwn an iPhone than OSX/Safari/etc.,

In real life iPhone is harder because you can’t just exec a shell (since there is no /bin/sh). You have to write your return oriented payload to do all your dirty work, which can be a pain. In Pwn2Own, you just have to prove you have code running, not actually do something useful, so the bar is lower. The only thing iPhone has going for it, which coincidentally is stopping me from attacking it this year, is a smaller attack surface. There isn’t as much exposed code on the iPhone. Safari for Mac OS X can do anything, render any file, etc. Not so on iPhone. There are some file types MobileSafari can’t display, some they display incompletely, and of course, iPhone lacks Java and Flash which comes by default on Safari. The easy to exploit bugs I know about happen to live in the code that Safari (on OS X) has but MobileSafari doesn’t, so no go for me.

Weinmann said finding bugs was easy but the exploit took a couple weeks to write due to crafting together a payload. By the way, Miller again — third consecutive year — pwned OSX via another Safari-related exploit.

Disabling Flash and Other Addons in IE8

March 19, 2010

Flash is ubiquitous, and that means it’s going to be one of the targets used by the criminal class to attack users. Most users allow it to run full stop regardless of whether they trust sites or not. This is probably not a good idea given the frequency of Adobe’s need to patch Flash. Flash should only be allowed to run from trusted sites, and probably only as needed.

I wanted to see if I could find something that would allow me to control when and where Flash works while using IE8 on my Aspire One. Turns out you don’t need an add-on to control your other add-ons — Microsoft enables such granularity within IE8.

Go to Tools-Manage Add-ons. Find Flash (you may have to select the “show all” option to find it). When you open the settings, you can “remove all sites” (the * wildmark is probably listed). Once you do that, you’ll be able to set new rules for which sites can run Flash on your computer.

When you hit a site with Flash content, you’ll get a notice on the top part of the browser area asking if you want to enable it. Select yes and you’ll allow Flash from that particular site. Don’t do anything and you’ll only be prompted again in the future.

You can (should) periodically review which sites you allow and remove ones you don’t want to permanently run Flash without interaction. This gives you, the user, ultimate control over which sites do what with your browser. And it’s not limited to Flash — you can set up and control all your add-ons the same way.

Update 20100304 – Debian Updates cups and sudo, Etc.

March 4, 2010

Over the past couple days, updates have been made available for sudo and cups. Make sure you keep your system patched no matter what operating system you use.

No changes in my own systems. My desktop remains unused. I’ve yet to sell my AA1 (let alone get it ready to sell). I’m still running Lenny on my laptop, still have Gnome bloatware installed even though I’ve been using ion2 and ratpoison recently. The latter remains my favorite, though I like ion* as well. I “fixed” the issue with byte-compiling mingus (mpd client) by installing the GTK version of emacs 22; now I run “emacs -nw” in screen. I’ll probably switch back to the backports version (23) or do a clean minimal net-install, like I should’ve done even though I needed everything ready-to-roll when I installed last time. I may have more time to fiddle with everything after next weekend.

But that’s what I always think.

 07:02:22 up 19 days, 21:10,  4 users,  load average: 0.05, 0.04, 0.10

Not bad for a laptop.

posted from weblogger.el

Debian Updates

February 13, 2010

Awoke this morning to find that Debian has patched for multiple issues. Also, don’t forget Debian stops security updates for Etch in a couple days.

Update 20100209 – Debian Lenny, TinyCore, emacs, ratpoison, oroborus, and security of small distros

February 9, 2010

I’ve intended to sell this thing but haven’t yet. I updated my AA1 page last week to reflect the fact that I really don’t run Linux on it anymore. I still have {Tiny,Micro}Core set up on it, but I’ve booted that maybe three times in the past few months including once this morning to get my emacs-related files. I don’t know if the issues with wireless were related to the network stack, the ath5k driver itself, wpa-supplicant, or a combination of factors. For the last time, it’s NOT a hardware issue because the problem never happened (meaning started) under Windows; it only happened (started) under Linux and persisted after rebooting. I occasionally boot TinyCore from a USB stick on my other computers (see below).

New Desktop/Workstation
It came with Windows XP Pro installed. I first installed Scientific Linux 5.4 via the live CD, which provides a Gnome desktop. I’ve already posted about adding an old hard drive that had OpenBSD 4.3 on it, on which I installed NetBSD 5.0.1 after backing up $HOME. I’ve been too busy to even update SL54 (which I know has updates because I was also running it on my new-old laptop for a while), let alone configure NetBSD beyond the basics (e. g., setting up my network card even though it’s not yet networked, SSH, etc.). I’d hoped to set it up further this past weekend but I’ve been eye-deep in a stack of reports to edit and charts to generate.

New-Old Laptop
I’m still using Debian Lenny, which I installed using net install. I let it go ahead and install the default Gnome desktop even though I initially thought about just doing a minimal installation and adding what I wanted. One of the reasons I did that is because life has been so hectic the past 18-24 months that I care a lot less about bloat than I do about the convenience factor and having everything ready to roll. Otherwise I’d already have the other computer set up and ready to roll, no?

I have switched some apps around, though. I was using xemacs but decided instead to revert to GNU emacs 21.4 from backports so I’ll have more of the modes I’ve come to take for granted and which require either finding via apt or from their developers. I’m posting this now via weblogger.el (which I’ll have to clean up later) from within emacs. I’ve also installed oroborus and am using it instead of metacity within Gnome (edit ~/.gnomerc to include a line “export WINDOW_MANAGER=oroborus”); this is RAM-sparing to some degree but not nearly enough. I already have ratpoison installed as well, and will more likely than not start paring down on the Gnome bloat as I find time. I’ve been running ratpoison mostly under another user account.

Other Computers
My ancient ThinkPad got a minimal install of Debian Lenny several months ago but hasn’t been booted in at least a month. I may use it for TinyCore. Or as I’d intended with Lenny just to be a temporary HTML/blog server for home use. I may just use MicroCore if I do that.

Nothing to report on my old MMX box. I haven’t booted it in so long I don’t even remember what it has on it.

Unfinished Business
Speaking of {Tiny,Micro}Core, I started on a screencast/presentation back before Christmas that I alluded to at least once here. I’ve been too busy to finish it. It’s in response to a question that was asked at the TCL forums about using TCL as an enterprise Linux replacement. I wanted to demonstrate beyond the more obvious answers why I thought it was unsuitable and worked out a quick and dirty concept to show how vulnerable such a distro — based basically on one file — could be. This kind of goes beyond the security of the image being read-only and, accordingly, being able to reboot into its original state; instead, I wanted to see how difficult it would be to take advantage of the fact that the image is on a read-write partition which can be mounted by user tc locally or remotely and then replaced. My little POC requires user interaction at this stage (which was in maybe 20 minutes’ work) to basically get a corrupt image to replace the original so that each subsequent booting of it isn’t actually the “pristine” original tinycore.gz image but instead the corrupted one (which could have any variety of “reconfigurations” in it, but mine basically pings another computer when it has an IP and has a message stored in a file stating what changes have been made to the original image).

I haven’t decided if I’ll go through and see if I can get it to work remotely without user interaction. Even if I do that, I won’t post it here. Sorry, kiddies.

Since these small image-based distros typically lack logging facilities, it would be trivial to pull this off and possibly leverage vulnerabilities in various packages to further make a mess of it. The smaller the distro’s base image, I think the less noticeable it would be. With my download speed, I can download the TinyCore image in just a few seconds.

Also, I tested this on USB. It’s trivial to test if something has been booted from sd{a,b} and contains a directory named boot containing a file called tinycore.gz. The same applies to other small distros which similarly use one file to store the operating system, allows full sudo (or, in the case of some like Puppy, root only), etc. Even though something is running from RAM, it’s still found on a storage device attached to the computer and can be mounted (unless it’s quickly removed). So I don’t think this is inherently more secure than anything else (or inherently secure at all), and the smaller size could be a disadvantage since it would take less time to download and be less likely to be detected by most users.

As improbable as it is that such things can be accomplished without some kind of user interaction or physical contact with a USB stick to install a corrupted image, it’s still possible. Add in potential vulnerabilities from various packages — including browsers, improperly set up servers, etc. — and the possibilities increase both locally and remotely.

No, the sky is not falling, but there is a potential for risk even though the image itself is read-only. The image may be, but its partition isn’t. The risk may be acceptable for most uses. It isn’t acceptable for enterprise use — not without some kinds of safeguards that enterprise distros have to help reduce problems like this from occurring.

I’m not knocking these small distros. I think they have a special niche, but too many people think they can be one-size-fits-all. Enterprise-grade distros — including RHEL and its clones, SLED, etc. — have a variety of safeguards that would be “bloat” in something designed to be small and minimal. Adding those things to a minimalist distro would seem to be counter to their very purposes. That includes everything from security enhancements to logging facilities (you really do want to know who logged into which computer at what time on what day, and having every user named “tc” can’t be of much use if you need a chain of custody for various computer records, file records, changes, etc.). Moreover, the packages or extensions these small distros offer typically don’t undergo the same level of testing as in enterprise distros, are more often than not bleeding edge rather than tested and stable versions, and aren’t signed. Even signed/trusted repositories aren’t free from trouble as the RedHat/Fedora people found out a couple years ago when their mirrors were compromised.

I’ll see if I can finish the presentation and get it posted soon. Then again, I thought I would’ve had that done a month ago. Stay tuned.

20090823 Update: AA1, Linux Security, TinyCore, Etc.

August 23, 2009

Quick personal follow up to my previous post about the latest, and probably most extensive yet detected, vulnerability in the Linux kernel.

I’ve been using my own kernel under what used to be CrunchBang. I can’t blacklist certain modules (e. g., bluetooth and IRDA) because I built them into the kernel rather than as modules. Yuck. Back to using the big-ass kernel from the repository if I’m going to use Linux. At least if I’m going to use my ex-CrunchBang install (it’s no longer even close to being what it was originally — from the window manager to the applications to my own kernel and so on).

I haven’t even booted into Linux since last week when my wireless crapped out under Linux again — I’ve had a busy week and this next one will be even more hectic. Right now, I’m not sure if I’ll bother upgrading again because I’m completely fed up with losing wireless and not being able to get it back without rebooting several times. As I noted, the crash and resulting videos came as I was making a screencast explaining why I dislike binary-based distros and their packaging and why I was more likely going to start using TinyCore more often.

Problem is, the same thing occurred one time under TinyCore. The ath5k time-out thing is not a distro problem. It’s a problem somewhere between the kernel/module, possibly WPA, and possibly a couple other things. So I have more than a reason or two to reduce my use of Linux on my AA1. I’m most likely reclaiming the larger partition I have set up for /home under CrunchBang for use under Windows (probably as an encrypted partition) and then using my 5GB partition for {Tiny,Micro}Core.

I’ve settled on another laptop and should have it next week. It’s not new — I don’t think I’ll ever again buy anything new enough that running Linux will be such a pain in the ass as it’s been with the AA1. The more bleeding edge the hardware, the more quirks and utterly stupid bullshit there will be with getting its glorious open source drivers to function properly and in some sort of stable manner. I checked all the specs to make sure Linux will have better support for the next laptop than I have on my AA1 now.

Right now I’m debating between Slackware (13 is almost ready) and CentOS 5.3, both of which have modern-enough kernels to support the hardware in the laptop. The reasons I’d install Slackware are for its lengthy support cycles and so I don’t have to download miscellaneous headers to (re-)compile anything. The reason for CentOS is to have an enterprise-grade distro with enterprise-grade support cycles (as in seven years). After all, I have to use this for my work. I can’t afford to randomly lose wireless (especially if it requires several reboots to get it functioning again) or to have to deal with freezing up when disconnecting the laptop from a projector.

I’m open-minded beyond those two distros. Even source-based since I’m going to have a few days around Labor Day weekend where I can leave it to compile all day long and let it catch on fire or something.

Back to the security issue affecting eight years’ worth of Linux kernels. Is {Tiny,Micro}Core a better solution for problems like this particular vulnerability? In some ways, it may be. It doesn’t come with a full set of modules. You have to install things separately because the whole concept is more modular. The kernel is read-only and in RAM. If someone were able to pwn at the kernel level, you can reboot into a fresh environment because the base system isn’t writable.

The counter to all that is, the more persistency you have for your installation the more vulnerable you are. Most of your configuration files are stored either in /opt or /home, which are read-write. Depending which extensions you use, you may have the same kind of exposure you’d have under any other distro.

And, most importantly, the weakest link in security is almost always the user. You can’t underestimate the problem users cause from clicking on links to opening things to setting up files so that anyone (aka “world” in Unix terms) can write or execute them. Some people ignore permissions altogether or set them up for the sake of convenience — such as other small/live distros that run only as root. I’m not saying that {Tiny,Micro}Core is inherently safer with its use of sudo (I wish more users would accept a default scheme which sets a random password so even running off the live CD or USB would require entering a password before mounting and erasing a drive, etc.).

So add TinyCore to the list with Slackware and CentOS. That may be the fastest way to get it up and running anyway. And TinyCore may be the last remaining Linux distro on my AA1 whether I run Linux on it again or not.

Linux Security Hole Goes Back Eight Years

August 23, 2009

Here’s another deep chink in the armor of the braindead zealots who claim Linux is inherently more secure than Windows. Julien Tinnes and Tavis Ormandy have found what could be the widest ranging vulnerability yet discovered in the Linux kernel.

Affected versions include all Linux 2.4 and2.6 versions since May 2001. This spans 2.4.4 up to and including in the 2.4 kernel and every iteration of 2.6 from 2.6.0 up to and including

What is this vulnerability all about? Functions in certain kernel routines are left uninitialized, so pointers aren’t validated before dereferencing. This allows local execution of code (sample POC available in both articles linked above) which compromises the machine. Compromise? Yes, pwnt.

These are known affected modules according to Redhat’s bugzilla:

That thread offers mitigation possibilities (and some commenters — see #32 and #48 — explain why those steps won’t work). According to post #27 in that thread, the exploit is already being used (as of about a week ago as I write this) to attack machines: “They entered the system through a web application exploit and then used the exploit to gain a root shell.”

This gets to the bigger problems of security. If you think of Linux as only the kernel or even the kernel plus the utilities that make it a functioning operating system, you’re seeing only one layer of vulnerability. Add another layer of complexity with various software and you’re adding more complexity and, accordingly exponentially more layers of vulnerability. If someone can get in through one door, he can often find “keys” to open other doors. That in a nutshell is what happens in cases like #27 in the Redhat bugzilla thread.

Fedora, Debian, and Ubuntu have reportedly already patched for this kernel issue. UPDATE: So has Slackware for -current and 12.2; patches are available for other releases with both 2.4 and 2.6 kernels.

New Zero Day – Linux Kernel

July 21, 2009

I’ve written repeatedly about the myth that Linux is inherently more secure. It always falls on deaf ears because some people don’t want to be bothered with the truth that all complex software is inherently vulnerable and insecure.

Here’s more proof that Linux has its own share of vulnerabilities.

The latest exploit affects kernel 2.6.30 and earlier versions. Bojan Zdrnja at Sans writes that Brad Spengler of grsecurity discovered this and adds:

Why is it so fascinating? Because a source code audit of the vulnerable code would never find this vulnerability (well, actually, it is possible but I assure you that almost everyone would miss it). However, when you add some other variables into the game, the whole landscape changes.

How so? Spengler writes in the comments to his POC that this vulnerability not only bypasses SELinux but is strengthened by it. Zdrnja explains:

While optimizing the code, the compiler will see that the variable has already been assigned and will actually remove the if block (the check if tun is NULL) completely from the resulting compiled code. In other words, the compiler will introduce the vulnerability to the binary code, which didn’t exist in the source code. This will cause the kernel to try to read/write data from 0x00000000, which the attacker can map to userland – and this finally pwns the box.

Is Linux or gcc to blame? Both/same. How many insist on “GNU/Linux”? Complex code, mutiple layers. So many links that there are bound to be some weak ones even if they’re not readily apparent by looking at the pieces rather than the sum of the whole. As Zdrnja concludes, “Fascinating research… again shows how security depends on every layer.”

Spengler’s solution is for administrators to compile the kernel with fno-delete-null-pointer-checks.

Remember what Linus said about masturbating monkeys? Or how many fanboi and other FSF-type sites raise anecdotal evidence about things like pwn2own as “proof” that Linux is insurmountable to attack or that Linux is more secure than Windows? It’s all bullshit.

Windows is more exploited because it’s prevalent. Linux has enjoyed security through obscurity, which is only obscurity and certainly not security. This isn’t the first or only exploit in the Linux kernel and it sure as hell won’t be the last. It really doesn’t help when so many in the Linux community — including Linus — are either nonplussed by vulnerable code, oblivious to security issues, or even willing to lie about it and spread their FUD that Windows is the only inherently insecure operating system and that Linux is inherently secure.

Time to get serious about security rather than treating it as an afterthought or engaging in deceit, especially if you want greater marketshare on computers, servers, phones, PDAs, DVRs/PVRs, or any other device that can run Linux. Otherwise, you’re a fucking joke.


UPDATE – 18:20 21 July 2009: I found more at Register about this:

The “NULL pointer dereference” bug has been confirmed in versions 2.6.30 and of the Linux kernel, which Spengler said has been incorporated into only one vendor build: version 5 of Red Hat Enterprise Linux that’s used in test environments. The exploit works only when a security extension knows as SELinux, or Security-Enhanced Linux, is enabled. Conversely, it also works when audio software known as PulseAudio is installed.

An exploitation scenario would most likely involve the attack being used to escalate user privileges, when combined with the exploitation of another component – say, a PHP application. By itself, Spengler’s exploit does not work remotely.

With all the hoops to jump through, the exploit requires a fair amount of effort to be successful. Still, Spengler said it took him less than four hours to write a fully weaponized exploit that works on 32- and 64-bit versions of Linux, including the build offered by Red Hat. He told The Register he published the exploit after it became clear Linus Torvalds and other developers responsible for the Linux kernel didn’t regard the bug as a security risk.

With millions of eyeballs, it still takes only two to find what everyone else can’t or won’t see.

Linus wrote that it’s not a Linux problem but a setuid problem, which Rob Graham of Errata Security points out is a “design ‘flaw’ that is inherited from Unix” that is “going to be with us for many years to come.” Ahh, yes. That’s the same ol’ Unix which some ignorant dolts wildly claim is what makes Linux and OSX and so many other things invincible and safer than Windows despite the truth. And ample evidence to the contrary.

Spengler’s beef now, though, is that Linus and his team haven’t clearly disclosed the problem. In complaining about the fact that his POC led to the issue being categorized as DOS, Spengler said, “It kind of makes the vendors think the security is better than it actually is.”

That should set off alarm bells to anyone using Linux, especially if beguiled about its inherent security.

US CERT Security Advisory – Firefox 3.5

July 15, 2009

US Computer Emergency Readiness Team (US-CERT) has issued an advisory about a zero-day exploit involving the JIT compiler for the JavaScript engine in Firefox 3.5. CERT recommends disabling JavaScript until Mozilla can patch; disabling the JIT compiler will reduce JS performance.

Secunia rates this vulnerability as highly critical.

iBotnet is a Warning – Mac Users Won’t Listen

April 23, 2009

Just read this article about the new Mac worm. I can’t agree with the writer’s conclusion that nothing needs to be done yet.

While this iBotnet worm will only affect those using pirated software (thus far: worms can be re-engineered to do whatever their designers want — see Conficker), other worms and virii will eventually and more easily affect other users.  Others are already being affected by this worm; it now appears the iBots are being used in DDOS attacks.

It’s a bit naive to say that paradise has been lost now with this worm when bots have been used for years for destructive and criminal purposes. PC bots don’t discriminate against Mac users, nor  do they ignore Mac users. Bots are used to spread more malware, to spam people, and to do all kinds of bad things and steal all kinds of data. The risks aren’t limited to one computer or one kind of computer when compromised machines — Mac, Windows, Linux, anything — spread risks to other computers and when they’re used in malicious manners.

The best security practice is pro-active rather than reactive. The writer of the “Paradise Lost” article is right that pirated software should never be downloaded, let alone installed. In addition to being illegal, you don’t know who’s done what with software. The number of unpatched and pirated copies of Windows in Asia accounts for the rise of botnets in that region of the world.

The writer is also very wrong to wait to install security software. You don’t wait for the hurricane to hit before you make your preparations. You make your preparations and hope for the best; you don’t hope for the best and then, when it’s too late, prepare yourself.

Those who wait to install security software have to hope they’ll have enough time to install it before any threat escalates into a Mac pandemic. Unfortunately, history isn’t on the side of those who wait too late in the game regardless of operating system. It’s almost always dead set against them. Zero-day exploits mean someone somewhere dropped the ball sufficiently for criminals to get an upperhand. It can take very little time for an exploit to spread, and many computers can be affected before the problem is even detected and, eventually, fixed.

In another way security software is like one of the common pro-gun rights mottos: It’s better to have it and not need it than need it and not have it.

Mac users have been beguiled for years into believing they’re elite, that Apple’s operating systems are invulnerable to cracking, that OSX’s Unix heritage makes it inherently secure (no operating system is inherently secure, not even OpenBSD), and so on. Their gullibility will likely prove their own downfall.

The time to get patched is before you’re cracked. The time to install security software is before you’re pwned. Then it’s too late. Duh.

Mac users will probably make for the easiest user community to target because they feel so invincible. It’s not if, it’s when. Mac users tend to have favorable demographics for criminals to target. Apple’s lax security policies make OSX a very easy target to crack. It’s a dangerous combination. The only question is, How many Mac users will be wide-open and vulnerable to attack because of their gullibility and naivete?

Even one would be too many. I expect mass pwnage, and probably sooner than later. And the compromised Macs will be used much as compromised Windows computers are. That means more malware, more spam, more distributed DOS attacks. Those who keep their computers patched and secure will be less vulnerable to the malware but will still be affected by those who are too stupid, ignorant, arrogant, or gullible to be safe.

Now is the time to prepare and reduce the risks of attack — before your Mac is attacked. It’s not too late yet.