Archive for the ‘internet security’ Category

Big Ruby Security Update, Disclosure Debate

June 24, 2008

Ruby has patched some very critical problems submitted by Drew Yao of Apple. “The vulnerabilities stemmed from unchecked overflow conditions in several array-handling routines, and from an unsafe memory allocation in Ruby’s string processing.”

Worse, “the vulnerabilities, which impact versions 1.8 and 1.9 of the interpreted programming language, could allow a denial-of-service attack or lead to remote compromise…”

Security company Matasano’s blog entry on the matter says the nature of the vulnerabilities sent chills up their spines.

All three published vulnerabilities allow normal Ruby code to be coerced into corrupting the memory of the interpreter. They involve integer handling errors in the native code backing Ruby’s Array, String, and Bignum classes. These are core classes in Ruby, and don’t depend on the libraries or extensions that programs load. The vulnerabilities, which are common to all large C codebases, exploit the fact that numbers “wrap” when they hit the largest size allowable by the CPU (usually 32 bits), and the fact that negative numbers and very, very large positive numbers share the same underlying machine representation.

The ability to overwrite memory in the Ruby interpreter is basically the same thing as the ability to upload native machine code into the interpreter. There are thousands of locations in memory that, if overwritten, can redirect code to unsafe libraries or directly into input buffers (such as the contents of web requests). The conditions under which the vulnerabilities are exploitable depend on the Ruby programs you are running. But don’t gamble. Update as soon as you can.

The nature of the problem and the minimal disclosure are leading to some measure of distrust and reigniting the debate over how much developers should inform users and how soon they should do it. On the one hand, developers need to give users a chance to patch before everything goes wild. Full, immediate disclosure of the nature of problems opens the door to exploitation of vulnerabilities.

On the other hand, as Zed Shaw has noted in his fast (“20-40 minutes”) analysis of the changes that illuminate the gravity of the problems in ruby, it’s not rocket science to see what’s been changed to understand what was fixed and why it matters. Anyone can do this, including the criminal class and they’re more likely than “good users” to scour code in the first place. The irony is the number of naive open source advocates (especially the fucktards who say or write things like “Linux is better than Winblows!”) who boast about code access but, short of having to compile what’s not yet in Ubuntu Universe, don’t do a damn thing with it.

That debate will continue to ebb and flow. What won’t is the fact that an attacker can execute arbitrary code and/or cause denial of service in a vulnerable version of Ruby on a server using it. At will, and trivially: “…this means that using nothing more than their own computer, someone could attack a Ruby-powered Web site, executing any programs they want on the server. If I know that your site is vulnerable, then someone with an understanding of the vulnerability could delete all of your files, or upgrade your operating system, or spy on your Web traffic. Needless to say, this is the sort of thing that you don’t want to have on any public-facing site.”

Patch. Review. Keep an eye on updates. Patch again. Repeat.

Debian and Derivatives (and Beyond) Serious SSL Advisory

May 16, 2008

HD Moore of Metasploit has tested a serious problem with Debian-based implementations — including Knoppix, Finnix, Mepis, Ubuntu and its derivatives, et al. — dating to September 17, 2006, of OpenSSL due to removal of code that was responsible for seeding random number generation (which is used to calculate encryption keys). This makes random number generation predictable and means keys are guessable/crackable. Moore writes that “Instead of mixing in random data for the initial seed, the only ‘random’ value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.”

Debian OpenSSL Predictable PRNG Toys:

If we continue this process for all PIDs up to 32,767 and then repeat it for 2048-bit RSA keys, we have covered the valid key ranges for x86 systems running the buggy version of the OpenSSL library. With this key set, we can compromise any user account that has a vulnerable key listed in the authorized_keys file. This key set is also useful for decrypting a previously-captured SSH session, if the SSH server was using a vulnerable host key…

The interesting thing about these keys is how they are tied to the process ID. Since most Debian-based systems use sequential process ID values (incrementing from system boot and wrapping back around as needed), the process ID of a given key can also indicate how soon from the system boot that key was generated. If we look at the inverse of that, we can determine which keys to use during a brute force based on the target we are attacking. When attempting to guess a key generated at boot time (like a SSH host key), those keys with PID values less than 200 would be the best choices for a brute force. When attacking a user-generated key, we can assume that most of the valid user keys were created with a process ID greater than 500 and less than 10,000. This optimization can significantly speed up a brute force attack on a remote user account over the SSH protocol.

In his FAQ, HDM says, “It took two hours to generate the 1024-bit DSA and 2048-bit RSA keys for x86” using 31 Xeon cores clocked at 2.33Ghz. He also adds that “It should be possible to try all 32,767 keys of both DSA-1024 and RSA-2048 within a couple hours” barring anti-brute force scripts on the server.

In my recent page for re-engineering DSL for traditional hard drive installation, I recommended updating zlib, openssl, and openssh because of the age and (in)security of the packages upon which DSL was built. Security is not a one-time shot, it’s a matter of persistence and requires constant attention and commitment. My page was published before becoming aware of this particular issue, which doesn’t affect DSL, per se, because the versions affected are Debian Etch and later; DSL was built on Woody, which predates Sarge and this particular Debian/SSL issue.

Unfortunately, this problem goes beyond just Debian users (and users of Debian-based distros like DSL) because of the number of certificates exchanged between secure sessions involving affected servers. Certificates from Debian servers — from banks, from websites, etc. — are affected regardless if the end user uses Debian, Slackware, FreeBSD, OSX, or Windows. As Moore adds,

In the case of SSL keys, all generated certificates will be need to recreated and sent off to the Certificate Authority to sign. Any Certificate Authority keys generated on a Debian-based system will need be regenerated and revoked. All system administrators that allow users to access their servers with SSH and public key authentication need to audit those keys to see if any of them were created on a vulnerabile system. Any tools that relied on OpenSSL’s PRNG to secure the data they transferred may be vulnerable to an offline attack. Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. This flaw is ugly because even systems that do not use the Debian software need to be audited in case any key is being used that was created on a Debian system.

The Debian advisory notes,

This is a Debian-specific vulnerability which does not affect other operating systems which are not based on Debian. However, other systems can be indirectly affected if weak keys are imported into them.

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.

The first vulnerable version, 0.9.8c-1, was uploaded to the unstable distribution on 2006-09-17, and has since that date propagated to the testing and current stable (etch) distributions. The old stable distribution (sarge) is not affected.

Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.

Anyone who’s used SSH and/or OpenVPN between their own and a Debian- or any of its derivatives- based computer/server needs to update and generate new keys. Users of all operating systems may also get pop up messages from their browsers over the coming days that secure sites they visit may have new or different certificates. I think users should read each new certificate to verify integrity because this could prove wide enough that criminals may take advantage of the confusion with their own dubious and insecure certificates, which could make a bad situation even worse.

This was a dumb mistake made by the removal of only a few lines of code. Sometimes dumb mistakes turn out to have the widest effects on users. Even those who don’t use Linux or Debian.

OpenBSD Gets WPA/2!

April 16, 2008

I was playing around with conky, setting up some RSS feeds and trying to decide if I wanted that junk forked into my background. Then I saw the news. Excellent!

OpenBSD is getting WPA/WPA2 support. It includes several chipsets including malo, bwi (new Broadcom 43xx support in OpenBSD 4.3 and DragonFlyBSD), ral, zyd, and others. More on the way. I wrote on my BSD blog that I would give the new bwi driver a shot but I haven’t gotten around to it yet. I definitely will now.

BTW, I decided one instance of conky is enough so the RSS one goes.

CanSecWest: pwn2own Wrap Up (Adobe Flash Causes Vista Laptop Pwnage)

March 29, 2008

Apple’s Leopard lasts ’30 seconds’ in hack contest:

“It might have taken eight minutes to sit down and open the computer but, when the competition started, 30 seconds later, it was over,” said Miller….Competitors in the hacking race were allowed to choose either a Sony laptop running Ubuntu 7.10, a Fujitsu laptop running Vista Ultimate SP1 or a MacBook Air running OS X 10.5.2.

“We could have chosen any of those three but had to make a judgement call on which would be the easiest and decided it would be Leopard,” Miller said.

Miller further elaborated, “I use a MacBook all the time and that’s what I used in the contest to attack the MacBook Air. I like Macs. That’s the reason I went for it; it’s in my best interest for them to be as secure as possible.”

Meanwhile, the Fujitsu with Vista (and Vista’s SP1) remained unscathed until late in the day yesterday when Adobe Flash was installed. Shane Macauly, who with the collaboration of Dino Dai Zovi pwned the Mac in last year’s pwn2own, used a new Flash 0day exploit to claim the Fujitsu and $5000.

Readers of my blog know I’m a proponent of flashblock and other extensions for Firefox (and Seamonkey) that help users whitelist trusted sites. Flash has proven susceptible to malevolence too many times to be allowed to run promiscuously, if at all. FWIW, I only use flash temporarily — install it, use it, remove it; so I use it only as needed — for dealing with youtube content.

Mozilla Patches Part Two: Huh

March 26, 2008

Mozilla fixes 10 Firefox flaws, half seen as ‘critical’:

Mozilla also patched potential identity leaks, spoofing bugs and cross-site scripting vulnerabilities in 2.0.0.13. But the fix that caught Storms’ eye was detailed by 2008-18, a fix for LiveConnect, a feature that harks back to Firefox’s predecessor, Netscape Navigator. LiveConnect lets Java applets call a Web page’s embedded JavaScript, or JavaScript access the Java runtime libraries, and it is used by both Firefox and Apple Inc.’s Safari 3 browser.

“Sun has updated the Java Runtime Environment with a fix for this problem. Mozilla has also added a fix to LiveConnect to protect users who don’t have the latest version of Java,” Mozilla said in the advisory.

“Here we have Firefox putting out a mitigation step for a bug in Java,” said Storms. “It’s a welcome addition when one vendor can help out another.”

All 10 vulnerabilities were also patched by the SeaMonkey Project, a separate open-source initiative that develops a multifunction browser suite.

The Thunderbird e-mail client, meanwhile, is affected by the five critical flaws listed in 2008-14 and 2008-15. “Thunderbird shares the browser engine with Firefox and could be vulnerable if JavaScript were to be enabled in mail,” read the first of the two bulletins. “This is not the default setting, and we strongly discourage users from running JavaScript in mail.”

A release date for Thunderbird 2.0.0.13 to fix the flaws has not been set. According to David Ascher, the head of Mozilla Messaging, the e-mailer’s update will follow Firefox’s by “several weeks.” In a post to his blog last week, Ascher cited several reasons why a simultaneous release of Thunderbird and Firefox updates was impossible. “Some of those resource contentions are due to not enough automation for the Thunderbird release process, and some of it is the consequence of not enough people with the right training,” he said.

Ascher defended the lag by noting that while JavaScript is turned on by default in Firefox, it is not in Thunderbird. “We could delay releasing Firefox until Thunderbird was ready, in the interest of mitigating the risk of someone using knowledge from the Firefox release to try and attack Thunderbird users,” said Ascher. “But that would mean leaving over 150 million users vulnerable. So, applying the correct math, we release Firefox security updates as soon as possible, and Thunderbird security updates as soon as possible.”

Nice that the Firefox people can help cover Sun’s asses but not Thunderbird’s.

Firefox, Thunderbird, Seamonkey Critical Update Released

March 26, 2008

Firefox update fixes critical security vulnerabilities:

A security vulnerability allows attackers to fake a borderless popup from a background tab using crafted web pages and place it in front of the user’s active tab. This could be used to spoof form elements and phish for data such as login data. Attackers can also circumvent the method used by some websites to protect against cross-site request forgery (CSRF) if server-side protection is based solely on referrer checking, as it is possible to fake the HTTP referrer (MSFA-2008-16). The Mozilla browser may reveal personal data if a user possesses a personal certificate which the browser presents automatically during SSL client authentication. According to security advisory MFSA-2008-17, following the update the browser asks the user before presenting the client certificate when it is requested by a website.

Most of the security vulnerabilities also affect the Thunderbird mail client and the Seamonkey browser suite. The security advisories refer to Thunderbird version 2.0.0.13 and Seamonkey 1.1.9, in which these bugs should be fixed. These versions are not yet, however, being distributed automatically. Firefox users should install the update without delay, as the vulnerabilities can be exploited using crafted web pages to inject trojans.

I was surprised by this when I fired up Windows today and was informed 2.0.0.13 was ready to install. User beware…

CanSecWest 2008 pwn2own: Triple Play!

March 25, 2008

nice toys for bad girls and boys
CanSecWest Applied Security Conference: Vancouver, British Columbia, Canada:

Three targets, all patched. All in typical client configurations with typical user configurations.You hack it, you get to keep it.

Each has a file on them and it contains the instructions and how to claim the prize. Targets (typical road-warrior clients):

  • VAIO VGN-TZ37CN running Ubuntu 7.10
  • Fujitsu U810 running Vista Ultimate SP1
  • MacBook Air running OSX 10.5.2

My bet is that the MacBook Err is first to go. Not just because it’s a nifty, thin lightweight machine many people crave but because Apple’s security blows. I won’t be surprised if the Fujitsu is last to go unless someone uses an identical expolit in the Apple, much like last year’s vulnerability was cross-platform. Since the Fujitsu will include iTunes, Safari, and QuickTime, I expect whomever pwns the Mac will immediately share the same exploit on the Fujitsu (or vice versa if it’s related to Apple’s insecure software). The rules stipulate one laptop per contestant.

FWIW, my heart would be set on the Fujitsu (on which I’d probably install FreeBSD) even though I’m a diehard ThinkPad fan. I’d take an x300 with its twice-better battery life (not to mention easy battery accessibility) and more USB ports and better connectivity and everything else over the single-battery (you have to disassemble the thing to replace it, which will reportedly take 48 hours at an Apple Store — no carrying spares) MacBook Err and the Vaio and the Fujitsu. Oh yeah, and then there’s the best part of all — the x300 doesn’t come loaded with Mac OSX.

If anyone at Lenovo wants me to review the x300 in a Linux/BSD environment, please contact me. I’d love to see what it can do.

How I Roll: sshfs

March 24, 2008

I’m not exactly a road warrior, but most of what I do is in the field. I’ve written in various forums that there are a few applications and utilities essential to me and “how I roll.” One of them is GNU screen. Another is SSH. These two allow me to work from the same session anywhere without ever stopping.

I’m also a huge fan of sshfs. This is a FUSE filesystem that allows a user to mount a remote home partition via SSH as though it were local.

Here’s a little tip if you’re working on a laptop in a situation where you have limited space on its hard drive, or if you’re in an area where there’s significant risk of losing your data through computer theft or some kind of disaster. It’s also cheaper than buying a new laptop hard drive.

Let me give an example. Let’s say you’re on your laptop at the university. There’s significant risk of theft of laptops and everything else. You need to work on your project but you want to insure you don’t lose all your effort in case your laptop “disappears,” if it gets dropped, whatever. You can lose an entire semester’s (or longer) work if something bad like that happens.

WIth sshfs, you can keep your work on your desktop (or server) computer at home. It doesn’t end up on your laptop’s hard drive, but you still have the easy and fast access as though it were because it uses the Unix idea of “everything as a file” in joining remote to local.

You would only need to run ssh on the computer at home so that you can access it remotely (and as securely or insecurely as you desire). On the laptop, you would run the fuse module and then enter the command:
% sshfs username@path.to.desktop.or.server: laptop.mountpoint/

So if your account name at home is “lucky” and you want to set a mount point (directory) on the laptop for “remote” it would look something like this:
% sshfs lucky@my.home.network: remote/

You’re asked to enter the password for user lucky and then that mounts the entire /home/lucky directory on the other computer to ~/remote on the laptop. Once you do that, you can transfer files back and forth as though it were all local — the same as any other files or filesystems mounted on your computer.

If you have a similar/compatible set of applications on both computers, you can also just get with it and use your remotely stored data files with your local applications. If you’re using Open Office’s calc or Gnumeric for your spreadsheets, you would just open whichever files from the remote computer on the local one. Then when you save, you’re saving remotely.

This minimizes the need to sync files between laptop, desktop, and/or server or keep up with multiple versions of the same data because you can use the same version universally. You can get by with less space on your remote/laptop hard drive if you have large files to work on. Just use your larger (cheaper) hard drive on your desktop/server for all your storage.

When you’re finished and want to unmount the remote system and terminate SSH, you enter:
% fusermount -u ~/remote/

Since it uses SSH, it’s more secure than a lot of other options including keeping data on tiny USB devices that can disappear even easier than laptops. And while there can be risk of theft of your desktop computer while you’re away, that risk is much lower if you use a bulky old (cheap) computer for such purposes. The more stuff you put in it to weigh it down (six combined floppy and optical drive slots don’t have to be filled with working — or even connected — drives), the less likely a thief will be interested in carrying it. Instead of adding another working computer (or broken floppy and Zip drives) to your local landfill, why not put it to good use?

It doesn’t need to be bleeding edge, you just need to be able to shell into it to access your safe data and have enough storage to make it worthwhile. It also doesn’t have to be big and heavy as described above — you could carry a “craptop” on campus and leave your good laptop in the safety of your home. Whatever you use can serve other duties as well if you put your mind to it.

And you can get by without ever touching your laptop hard drive (or needing one). Some Linux live CDs, including Damn Small Linux, come with FUSE and sshfs. Since DSL contains extensions like Open Office, Abiword, Gnumeric, etc., it would be quite easy to work remotely like this.

Both FUSE and sshfs are available with nearly all Linux distributions or should easily be added if not, as well as for FreeBSD and NetBSD (possibly other smaller ones, but not to my knowledge in OpenBSD). More FUSE fun soon.

Firefox 3 Initial Impressions – VectorLinux Site Hacked

March 21, 2008

I read an article that the Mozilla folks are so proud of Firefox 3 beta 4 that they’re encouraging it for average users. So I decided I would give it a spin.

I downloaded the tarball and set it up in /opt. From a console, I opened it up. I got the first box asking if I wanted to import my bookmarks and settings from Seamonkey (which was installed by default in Vector, and which I manually upgraded rather than using their package because I didn’t want to slow my computer down with all the slick Vector imagery — an issue which I’ll address soon). I did. It then announced my settings were brought over and asked if I wanted the Mozilla search page or my existing home page. I selected my home page.

Then the fun began. Some Arabic writing appeared on the window title bar. And in the tab. My first concern was that I had downloaded an Arabic version instead of the American English one. Looked at it. Umm, nope. Got the right one.

Vector apparently opens to their website when browsers are fired up the first time. That’s another peeve of mine — when someone insists on including configurations that direct me to their sites (you think six links to different parts of the site aren’t enough? am I really important enough to count me when I run seamonkey and firefox the first time?). In the process I found out their site’s been hacked.

This is a later shot when I realized what was going on (and I left open a tab when checking on this to make sure the file I downloaded didn’t have any known issues). But you get the point.

When I realized what was going on, I decided to open the site in dillo and that’s when I found out the criminal did a bit more. Dillo displayed it, Firefox resulted in a 404.

Anyway, hitting a hacked site because the distro I’m using includes a hit to that page in the default install even if I don’t use their packaging has given me a more negative impression of Vector than Firefox. I’m sure others who are using Vector for the first time this evening have the same impression — maybe worse.

I haven’t had time to weigh how much better Firefox 3 behaves with respect to memory, nor have I had time to delve into any new features. So far I see a familiar interface that handles things identically to earlier versions. I’ll have more time this weekend to try it out.

Microsoft New Patches for Office Vulnerabilities — Got Root?

March 12, 2008

This rant is targeted at those who run Windows as root (administrative users in NT, ME, XP, and Vista) exclusively. It also applies to those who run as root in Linux, BSD, and OSX as well. Or any other OS that runs as an all-powerful single user.

It really does make a difference how users run their computers when it comes to vulnerability levels. This is especially true with Windows because of the number of criminals focusing on the most popular platform. Many users either fail to read the documentation to understand how to maximize the security levels afforded by having different accounts or they choose the convenience of running as administrator all the time. So if and when they get some kind of malware in their admin account, it affects the entire computer.

That’s dumb. There’s no need to run entirely as root regardless of which operating system you choose to use.

Microsoft released a critical patch set yesterday for remote exploits that affect Office packages including Excel and Office Outlook. Mac versions of Office 2004 and Office 2008 are also affected by one of the vulnerabilities fixed in this set (that exploit involves a “maliciously crafted” Excel file granting remote control of a system).

Microsoft Patch Tuesday Fixes A Dozen Office Flaws:

Andrew Storms, director of security operations at nCircle, said this month’s patch cycle represented a “shining example” of mitigating Microsoft Office vulnerabilities. He noted that Office users without administrative privileges won’t be affected by these flaws as much as users running with full privileges.

Storms also said that Microsoft’s newer Office apps appear to be less vulnerable than its older ones. “When the support line for Office 2000 and Office 2003 drop off the board, we’re probably going to see a pretty significant reduction in Office vulnerability,” he said.

I think Microsoft has an unfair rap when it comes to security. How can they be blamed for (a) user choice when it comes to running with root privileges and/or without firewalls and other sensible measures or (b) their market share which makes them big targets for cybercriminals? If things were reversed and Apple had dominant marketshare, we’d hear a lot more about how vulnerable their operating system and applications are because that’s where the criminals’ attention would be focused.

I also don’t think open source is always the answer when it comes to these kinds of security issues. I remember some of the exploits discovered in Open Office, including the infamous French military analysis: “A number of the problems described in the report have to do with the basic design of the software. For example, OpenOffice.org does not perform adequate security checks on the software it runs, the researcher said. And because of the extreme flexibility of the free office suite, there are many ways for writers to create malicious macros, the researchers found.”

Yes, much of that changed in subsequent releases. No, the threat is not over. The Open Office website has its own security section, just like Microsoft’s site does. The Open Office site admits that their project “is a complex piece of software developed by various teams” and accordingly “it can contain security relevant bugs.”

Similarly, there are many Linux users who run as root — the thirteenth most popular distro in Distrowatch‘s list (as I write this) runs exclusively as root and I can think of a few more live CD-based distros that do as well. I don’t buy the safety of a read-only OS that restores when the system is rebooted: data on any hard drive or mountable partition is vulnerable both locally and remotely. I also can’t tell you how many times I’ve seen Macs run in single-user mode as root — seems to be the norm rather than the exception. And they’re using insecure public hotspots!

As long as there’s money to be made from spambots and identity theft or pleasure to be gained from pwning someone else’s system, there will be threats regardless of which operating system and software packages are most popular. The solution isn’t a one-size-fits-all adoption of open source or falling prey to stupid ad campaigns that anthropomorphize computers. The solution is in educated users who are on top of their systems regardless of what they choose to run.