Archive for September, 2006
Dino Dai Zovi | September 29th, 2006 | Filed Under: Apple, New Findings
Release Date: Fri Sep 29 2006
Synopsis
MacOS X uses Mach exception ports to support the CrashReporter “Application Quit Unexpectedly” dialog, Problem Report dialog, process debugging, and crash dumps logs.
On vulnerable operating systems, attackers can exploit the inheritance
of Mach exception ports to inject code into SUID processes,
allowing nonprivileged users to assume root privileges.
Background
In Mach, tasks communicate with each other through the basic IPC primative, Mach Ports [1]. Ports are the basis of Mach RPC and are also used to identify and communicate with other tasks and threads.
The Mach security model is based on “port rights”, the right to send
and/or receive messages on these ports. Having port send rights to another
task port allows one to fully control that task by reading/writing its memory and controlling threads belonging to that task. A special type of port, exception ports [2], allow another
task to be notified when a process generates a hardware or software exception.
In a Mach-based Unix operating system, each Unix process has a number of
default ports that allow it to communicate with other tasks, including
the kernel and its parent process. Under MacOS X, the exception ports are usually set to a port owned by crashreporterd so that it can generate crash logs when an application crashes.
A number of MacOS X kernel vulnerabilities have been discovered by exploiting the difference between the Unix and Mach security models. Mach, for instance, has no notion of setuid processes or even users for that matter. Obtaining port send rights to the task or thread port for a process you don’t own gives you complete control over that process. This vulnerability in the MacOS X Mach exception handling that allows just that.
MacOS X includes a number of kernel-based Mach RPC servers. One such
server is the Mach Exception Server (exc_server). The Exception
Server decodes exception messages from a Mach task and dispatches the
exception to callback functions defined in the caller.
The exception handling callbacks are called with the Mach
ports of the task and thread where the exception occurred as parameters and have send rights
granted on those ports.
A number of Mach-based Unix operating systems (including MacOS X and
OpenStep) allow SUID executables to inherit the parent processes’
exception ports. When an exception notification is received, the
parent calls the kernel exception server exc_server() to process the
exception and call any of a set of defined callback functions. The
catch_exception_raise() callback is given Mach port send rights to the
Mach thread that generated the exception and the task containing the
thread. These rights allow the parent to modify the thread’s context and the
task’s address space. A parent process may exploit this by allocating
memory in the child task’s address space, copying in executable code,
and causing a thread in the task to execute the injected code.
Exploiting this vulnerability requires a SUID root executable that can
forced to generate an exception. A number of common setuid root
binaries like /usr/bin/at or /usr/bin/rlogin crash when executed with
a NULL argv pointer, and this suffices to enable exploitation of this
vulnerability.
Target
This vulnerability has been exploited on MacOS X 10.4 and 10.3 and verified to exist on OpenStep 4.2. It is assumed that releases of MacOS X prior to 10.3 are also vulnerable, as well as earlier releases of OpenStep and NeXTSTEP.
Impact
Unprivileged attackers with local access can obtain root credentials.
Vendor Response
Apple has resolved this vulnerability as of MacOS X 10.4.8.
Workarounds
As this vulnerability exists in the operating system kernel, there are
no known workarounds.
Origin
Dino Dai Zovi, Matasano Security
ddz at matasano.com
For more information on this advisory, please contact
advisories at matasano.com
References
[1] J. Boykin, D. Kirschen, A. Langerman, and S. LoVerso. Programming under Mach.
Addison-Wesley, 1993.
[2] David L. Black, et al. “The Mach Exception Handling Facility”
6 Comments
Nate | September 29th, 2006 | Filed Under: Defenses, Guests, New Findings, Uncategorized
«Previous: Attacks on Other Algorithms | [Top][]
If you missed out on the analysis of RSA and other public key implementation security, here’s a summary of all that we covered.
Footnote: why RSA-PSS is not a panacea
We hope you enjoyed the series and learned something about the many ways public key crypto can fail if not implemented perfectly. If you are thinking about implementing your own public key crypto, think again. If you’re responsible for maintaining existing libraries (or a security researcher), there are plenty out there still vulnerable to the flaws we described. Please change that!
Sincerely,
Nate and Tom
4 Comments
Dave G. | September 28th, 2006 | Filed Under: Apple
We are days away from Dave Maynor and Johnny Cache’s ToorCon talk. There is no doubt that their talk is going to be interesting. There are a couple of ways this could go down:
They don’t talk about the Apple situation at all. Certainly the easiest option. Let people think what they are going to think. Would be hard on the ego if they had something. Would be easy on the reputation if they had nothing.
They insinuate but do not prove. Also easy. Tell a story about how bad Apple is/was to deal with. Easy for people to believe that vendors are bad.
They prove they have/had a vulnerability. A little harder. Brings up a lot more questions. Did they provide enough information to Apple? Is it fixed? Did they reverse the patch and write proof of concept code?
They prove they have an exploit. Pretty much the same as #3. Only the question is whether they could have reversed and written a remote kernel (heap) overflow in ~9 days.
Hopefully, whatever happens at ToorCon will end things, and we can move past the Perfect Storm of Disclosure.
12 Comments
Thomas Ptacek | September 28th, 2006 | Filed Under: Defenses, Disclosure, Guests, Uncategorized
«Previous: Eight Other Attacks | Top | Next: Conclusion»
Remember what we said in part 2 of this series? Public key crypto
algorithms are based on number theory. Think of the words “number
theory” as code for “fails catastrophically in the face of
implementation errors”. The recent RSA signature vulnerabilities
negated the security promises RSA sets up for SSL; that’s a terrible
flaw. But we can survey publicly-deployed implementations of other
cryptosystems and find significant numbers of similar attacks. For
example:
Elliptic Curve-based Systems (ECDH, ECDSA)
Elliptic Curve (EC) cryptosystems are public key schemes based on
equations originally designed to measure ellipses. The underlying
mathematical problems involved in EC are significantly harder to solve
than those used in multiplicative-group systems like RSA; this means
EC cryptosystems can often achieve security with much smaller key
sizes, making them popular.
To set up EC cryptography, parties need to agree on “domain
parameters” (the finite field, curve, point, etc). When one party
accepts another’s generated parameters, they need to be validated
carefully; otherwise an attacker can
forge signatures or obtain your private key.
Do you work in security? You’re more likely to be called on to
evaluate an EC implementation than to write one yourself, especially
because you’re probably too smart to fall into the trap of writing
your own crypto. So, next time you come across someone else’s vanity
EC library, look for missing steps in this sequence:
Check that q is a prime power
Check that E is an elliptic curve over Fq with cryptographic
restrictions (order of #E(Fq) = kr, where r is prime)
Check that G is a point on E(Fq) of order r
(source: Kaliski’s EC summary)
Secure Remote Passwords
The SRP protocol is a “zero-knowledge” password proof scheme that uses
math similar to Diffie Hellman to allow two parties to prove they
share a password. The draw is that neither side needs to share
anything other than information derived from the password (like
pre-exchanged keys, or a trusted mediator).
Like other public key cryptosystems (SRP is basically a public key
scheme that generates ephemeral keys), SRP parties must agree on a few
published parameters (prime numbers, a generator, etc). As with EC,
when Bob receives parameters apparently generated by Alice, Bob needs
to verify them. The specification gives
explicit step-by-step procedures for doing this
(a plus for the SRP spec). But not all
implementations perform all those steps, meaning an attacker can log
in as anyone without knowing your passwords.
The following is a list of constraint checks that must be performed
by both sides to ensure the security of the SRP protocol. Client
testing of n and g is only necessary if these values are transmitted
and not embedded or prearranged. n is a large safe prime (client).
g is a primitive root of GF(n) (client)
Assuming the factorization of n - 1 is known, the algorithm
described in [16] for testing generators can be used to verify
g. If n is a safe prime, this test is particularly easy and
fast.
A > 0 (server) (mod n)
This prevents the server’s session key from being forced to a
known value, namely zero.
B > 0 (client) (mod n!)
This check prevents a dictionary attack on the password from a
masquerading host.
a, b > log[g] n
The computations of g^a and g^b in GF(n) must “wrap around”
to prevent an attacker from taking the algebraic logarithm of
g^a to recover a. The probability of this happening is
infinitesimal (less than 2^-1014 for 1024-bit n), but the
check is trivial.
The client must ensure that n is large enough to resist attack; see
Section 4.4.1 for recommendations. Using a probabilistic primality
tester, the client should also ensure that both n and (n - 1) / 2
are prime.
Diffie Hellman
DH is a workhorse of modern cryptosystems, and it’s so simple that
it’s well-captured by a few paragraphs in Wikipedia. But like our
other examples, it’s based on number theory and parameter negotiation,
and, as a result, the implementors of Tor broke it: if the two sides
of a DH negotiation don’t check the exponents they receive, a
man-in-the-middle can spoof handshake messages and predict the
resulting key.
An implementation has to check for the following bad values to avoid
attacks, including “small subgroup confinement”.
Exponent of 0, p, 2p, …
Exponent of 1, p + 1, 2p + 1, …
Exponent of -1 (p - 1, 2p - 1, …)
Resulting shared secret Z is not confined to a small subgroup. Check that (Z^j) mod p != 1, where j = (p-1)/q
Or, p must be a “safe prime” (p = 2q + 1 where q is also prime)
Careful: these lists aren’t complete. It’d take pages to explain
how to perform the checks correctly; don’t depend on a blog post to
determine the absence of a flaw. But there is definitely some
low-hanging fruit out there that doesn’t even do basic checking, and
hopefully we’ve just helped you pick them.
We also wanted to show that the problem is much bigger than RSA and
certainly not limited to low-exponent RSA. In all cryptosystems,
especially public key systems, any variability an attacker can
influence can lead to catastrophic failure. The verification of
parameters needs to be performed via a simple, easy-to-audit method
that can be shown to be complete. And if you’re testing a product that
depends on a public key algorithm for its security, you can often
glean a catastrophic finding by looking at these areas of the
implementation.
Next: Conclusion»
4 Comments
Thomas Ptacek | September 28th, 2006 | Filed Under: Gatherings, Uncategorized
Hey Marty! Ron! Get your teams over to Red Siren (whatever that is). Richard Bejtlich’s NoVASEC CitySec gathering is tonight. All the cool kids will be there.
Oh, you’re not Marty or Ron. But you’re in DC too! And you read us! You should definitely go to NoVASEC. It’s at 10790 Parkridge (St 300) in Reston. Richard promises to hold the next one at a bar. With free beer. But this one will be cool anyways.
You do not need to RSVP. Just show up.
See you there! (*)
(*) No, I won’t.
1 Comment
Thomas Ptacek | September 28th, 2006 | Filed Under: Industry Punditry, Uncategorized
1.
Alan Shimel responds to an InfoWorld brief on Vyatta, the XORP Open
Source Router startup:
The answer is not to play the same old, same old game but
cheaper. Introduce new features and technology into the mix. Linux
does not compete with Windows because it is free or cheaper, it
works better and offers things Windows doesn’t.
So, I agree with this. We wrote about Vyatta a couple months back,
pointing out:
The IP forwarding battle is over switching, not routing; no
router startup is going to change the world anymore.
The capex cost of the router is negligable compared to the
opex cost of managing the connection; a $0 router could lose
to Cisco today.
If you don’t have the equivalent of the Cisco ISR, you don’t
have a competitive router; Vyatta doesnt.
Open source routing is old news. Why didn’t NextHop or
IPinfusion win here?
2.
But here’s something InfoWorld quotes, and Alan lets slide:
We understand [Cisco] has an 80% market share and that routing
protocols haven’t changed much since Methuselah,” Herrell said. “But
we’re taking on the myth that routing requires specialized protocols
by offering an open alternative.
Does anybody really think that lack of routing protocol innovation is
stifling the industry? Most enterprises —- no, wait, virtually all
enterprises —- barely touch the IOS defaults, or even break out OSPF
areas. And that’s real enterprises. A majority of the SMB businesses
Vyatta targets won’t even use routing protocols (note to Roland:
static doesn’t count). There are three things about this argument that
annoy me:
Routing protocols aren’t in play in Vyatta’s game.
There’s nothing decrepit about OSPF (ok, maybe BGP4 is a
fair target, but 0% of SMBs are even in a position to use it).
This isn’t even a good marketing spiel for Vyatta; what is
a potential buyer supposed to take away from this, that
Vyatta wants to use strange new protocols?
3.
Finally, just to be mean:
Vyatta OFR is targeted against Cisco routers like the 2821 and 3845,
which cost about $4,000 and $13,000, respectively. In contrast,
Vyatta OFR hardware plus one year of support comes in at “just under
$2,000,” the company said.
The thing about having a 600 page product list is, you can always find
a Cisco part that sounds similar to yours that will list at 14x
yours. In reality, at “just under $2000”, Vyatta isn’t even competing
with Cisco on price. $4000? Give me a break.
1 Comment
Thomas Ptacek | September 27th, 2006 | Filed Under: Gatherings, Uncategorized
Hey you! Over there. Yeah you, at your keyboard in Billerica. Yeah, Billerica counts, yo. Boston’s most credible security meetup is tonight. Starts at 6:00PM. In Cambridge. Enormous Room, 567 Mass Ave. Get out there, and harass Chris Hoff about his vendor allegiances.
If I haven’t convinced you, maybe this will.
No RSVP necessary. Just show up.
2 Comments
Thomas Ptacek | September 27th, 2006 | Filed Under: Defenses, Uncategorized
Jeremiah Grossman writes my favorite websec blog. It’s regularly
updated, high-quality, and I learn stuff from it. Today he’s
sounding the alarm over Cross-Site Request Forgery (CSRF).
CSRF is a very, very simple idea. You can make a browser issue an
arbitrary HTTP GET and POST request. It’s easy. For example, stick the
query you want in an IMG tag. Or use Javascript or FORM tags.
This is a problem. Some of the people you trick into making those
requests will have logins on the target server. Some of the request
could do damage.
Like Javascript Injection (XSS), CSRF has a lot of potential to cause
lots of damage while flying under the radar for years because the cool
kids aren’t impressed by it. On the one hand, the risk behind CSRF is
mitigated because it’s harder to make money with it than with XSS; on the other
hand, it’s much harder to fix than XSS.
11 Comments
Thomas Ptacek | September 27th, 2006 | Filed Under: Industry Punditry, Uncategorized
I’m quoted in several places in Dark Reading’s recent
roundup of six hot new security products. I agree with some of their picks, and not
with others. But hey, it’s a great excuse to do my own roundup. Duck!
Six H0t Security Technologies For 2006
Coverity: Static Code Analysis.
Sometime around 2004 something happened; static code analysis
started to work. Static analysis takes raw source code,
figures out what it will do (without actually running a real
build of it), and uses that to find bugs in the code. For
almost a decade, the leading alternative to static analysis
(“dynamic” analysis —- programs like Purify and valgrind —-
which actually require you to run your code and work via
runtime checking) had so kicked static’s ass that I’m sure
some people had written it off.
Static is back with a vengeance, led (in my opinion) by Bay
Area startup Coverity. Brainchild of a Stanford team led by
Dawson Engler, who Tim Newsham sends me papers from, Coverity
has made a name for themselves by offering their technology to
open source projects free of charge; unlike some other
companies in the space, Coverity’s results have garnered
accolades, and Coverity has racked up an impressive customer
list.
Static code analysis opens up a debate about whether code
analysis or fuzzing finds more bugs. Right now the needle
seems to point in fuzzing’s direction, but it’s silly to think
that either approach offers a complete solution, and, in the
meantime, the debate is healthy.
Tenable PVS (fka NeVO): Passive Scanning
In 2001, my then-business-partner Dave Meltzer proposed a
security startup that would offer something that looked like
an IDS, but instead of detecting attacks, it would detect
vulnerabilities. “That’s a retarded idea!”, I seem to recall
asserting. “You’ll miss 50% of what an active scanner will
pick up. It’s just a gimmic!”
Fast forward five years; I’ve had the experience of adding an
innocuous active scanning feature (port probes only) to an
otherwise passive product, and having the DoD inform me that
it wasn’t enough to have it off by default: we had to mangle
the UI to make it impossible for an analyst to accidentally
enable it. Scanning scares the shit out of network managers,
and probably for good reason.
I was wrong, and Dave was right, but it’s Ron Gula who’s going
to clean up on the idea, which he and Renaud Deraison at
Tenable had independently of us. PVS is a “scanner” you can
deploy passively; it sits there, benignly, like the network
security equivalent of those Roomba vacuum robots, finding and
reporting vulnerabilities. Like the Roomba, it isn’t going to
clean up everything, but the effort (and risk) involved in
using it is so low that you’d contemplate buying something
that sounds as silly as a little robot that goes around
vacuuming your house. Or a sniffer that detects vulnerabilities.
Voltage IBE: Identity Based Encryption
Here’s what an SSH key looks like:
1024 35 24c77738636c56409ee30dea2a4c7aa80c14dd58034541b5
09039832881c2d505b387405987e80fb4de94b2ae3fbecf61d7fb185
8f8745e302de089ed087067a90fa2b070f98b34d2ce2c599f450477e
586492a4fd5141af25ada8926964a1ec2cac616d7b91ee7db010c6dc
b8004e65b5a4322904f64c3f48b8a8ca7fa31db22e1416e foo@bar.com
Here’s what an IBE key looks like:
foo@bar.com
What’s the catch? To encrypt a message to foo@bar.com, you
need a one-time relation to a key server, which feeds you
elliptic curve parameters. From that point on, you can encrypt
to foo@bar.com, or, 2 years later, without contacting the
key server again, when you hire baz@bar.com, to her as well.
How does it work? The key server gives you enough information
to use a hash of a string as point on a curve, and then use
that point to synthesize a public key for a key pair that only
the key server will know. The key server dutifully provides
that key pair to foo@bar.com when he authenticates himself;
this is, again, a one-time relationship.
Why is this so cool? As a small example, think about
provisioning SSH access. Want to securely add
“tqbf@matasano.com” to your shell server? Try:
echo tqbf@matasano.com >> ~tqbf/.ssh/id_ibe.pub
That’s it. No “secret handshake”, no
man-in-the-middle. This is space-alien technology, recovered
by Stanford crypto prof Dan Boneh from a crashed saucer
site in Half Moon Bay. Unfortunately, from what I can tell, this
SSH functionality doesn’t exist, and Voltage is spending their
effort on secure email, which I think is a waste compared to
the immediate $5+Bn market opportunity for systems
management. But what do I know?
PaiMei: Assessment Accelerator
My obligatory open source pick, PaiMei is a gathering storm of
dynamic code analysis security tools built around a
programmable debugger written entirely in Python. If you don’t
know what all of that means, that’s fine: find your friend who
reverse engineers Windows binaries and ask him, but don’t
forget to bring a towel to mop up the drool.
The tightest thing PaiMei does right now is hit-trace diffing
(“Process Stalking” in author Pedram Amini’s lingo). Process
Stalking eliminates whole swaths of code from consideration
during a test by allowing you to isolate the specific code
that executes during a test case (say, on receipt of a
packet), while excluding all the background noise. On a real
project for a real program, where you’re dealing with tens of
thousands of subroutines scattered across 20 DLLs, this isn’t
just a cool feature: it can speed up an evaluation by an order
of magnitude. Do you reverse engineer code? This tool prints
money.
Right now PaiMei is built around Python hooks to Microsoft’s
native debugging libraries. That means it’s Windows-only. But
the basic concepts the PyDbg debugging core are built around
are simple (a breakpoint is just an instruction you write into
the memory of a process that halts execution); multiple people
are working on Unix ports, and I eagerly await agent-based
remote debugging. Better still, there are promises of a PaiMei
extension that eliminates the dependence on IDA Pro.
802.11x VLAN Assignment: Restoring Order To Internal Networks
In the category of “hot security tools you’ve had for three
years but didn’t realize”, we have dynamic VLAN
segmentation. In 2006, there is no reason your helpdesk
workers should be able to talk to your mainframe batch
processing systems or (god forbid) your storage networks.
Forget about NAC. The problem is not that infected laptops can
get access to your network; infected laptops are always going
to screw things up for you. Smart network architects don’t
waste time trying to eliminate the inevitable; they focus
their effort on mitigating its impact. Ask yourself the
question: would you rather be 80% effective at preventing one
network worm a year (but not email viruses!), or would you
rather make it so that your sales guy can’t even talk to 80%
of the systems on your network?
Network segmentation is the great challenge of internal
network security. No matter what flashy boxes you pilot in
your Des Moines branch office or plug your conference room
jacks into, the goal of internal security is the defense of
assets. NAC defends ethernet jacks, quite possibly your single
least valuable IT asset. Segmentation defends everything else.
Next-Gen Attack Tools: Black Box Vulnerability Testing
And finally, the “we’re too chicken to crown a king”
multi-pick: the hardcore assessment tools.
Led by the pioneering CORE Security and loveable iconoclast Dave
Aitel’s ImmunitySec, this space began as a toolkit for
penetration testers, which is to say, as consultingware. But
the last few years have witnessed drastically increased
interest in testing gear before it’s deployed, and the
realization that it doesn’t matter if you crash something if
it’s a QA deployment on a lab network. As a result, CORE
IMPACT and Immunity CANVAS are now staples of enterprise product
evaluations.
With the positioning battle settling down and the niche
established, we’re seeing new entrants. The space now looks
like this:
The Runtime Proxies: IMPACT and CANVAS have at
their core a “runtime” for exploits that allows them
to benignly infect a vulnerable victim and then
leverage the infection RPC-style to conduct further
attacks.
The Fuzzers: Codenomicon and ProtoVer: commercialized
fuzzer tools designed to exhaustively exercise
protocols; scourge of SNMP and LDAP implementations
over the last four years.
The Appliances: MuSecurity and upcoming BreakingPoint:
promises a synthesis of tools like IMPACT and “pure software
fuzzers”, built for speed and with a focus on lab
network product evaluation.
Three of my picks have as their core value prop “eradicating
vulnerabilities from insecure software”. This is where one of the most
meaningful battles in security is being fought: can we make a dent in
the problem by “fighting them over there, before we fight them here”?
I’ll concede that it’s an open question, but I’m hopeful.
5 Comments
Thomas Ptacek | September 27th, 2006 | Filed Under: Defenses, Industry Punditry, Uncategorized
Chris Hoff writes (ostensibly) about third-party patching, employing a
paeon to Bleu Lane so wrong headed that I’m left to wonder whether pod
people have taken over his brain.
Bleu Lane, for those of you who don’t keep track of these things,
sells something they call “inline patching”. The idea is, well, I’ll
let their pictures explain it for you:
![[before]](http://www.bluelane.com/lib/img/ActiveFixExample1.png)
![[after]](http://www.bluelane.com/lib/img/ActiveFixExample2.png)
You see what they did there? The box takes in shellcode, and then, by
“emulating the functionality of a patch”, spits out valid
traffic. Wow. That’s amazing. Now, somebody please tell me why that’s
any improvement over taking in shellcode, and then, by “emulating the
functionality of an attack signature”, spitting out nothing?
Yes, the problem with Bleu Lane Patch Point is that it doesn’t seem to
be anything more than a slick marketing story over conventional
IPS. Even the message is derivative; ISS used it for RealSecure four
years ago. But unless you fund a marketing team millions of dollars to
lie by repeated assertion, nobody believes that this is the equivalent
of patching.
But that rant is actually a digression from my actual problem with
Hoff’s post. Because even if it worked, Bleu Lane has nothing to do
with third-party patches.
The power of a third-party patch is that by preempting the vendor,
vulnerabilities can be disclosed without waiting. Real third-party
patches are inherently “zero-day” patches; what to do with a zero-day
patch is a decision you’ll have to make days before an IPS engineer
figures out what to do with it.
I’m willing to believe that Chris’ bacon has truly been preserved by a
PatchPoint appliance (though I’ll point out that if he bought one two
years ago, he apparently had a beta: PatchPoint launched in
September ‘05). He’d be telling one of the first stories of
someone getting actual protective value out of an IPS, but I’m willing
to believe it. I’m also willing to believe that Chris’ interests are
profoundly aligned with promoting network-based solutions to security
problems, and that they tend to be aligned with promoting network
vendors as well.
Am I wrong about PatchPoint? Let me know.
25 Comments
