Archive for April, 2006
Dave G. | April 28th, 2006 | Filed Under: Matasano
nCircle has a blog post on the difference between writing exploits and writing vulnerability checks (think nessus). The basic summation is that they are two different skillsets that aren’t necessarily present in the same person, and that maybe one is harder than the other.
Or, in other terms, vuln check writing is more of a ’strategic’ pursuit, whereas exploit writing is more ‘tactical’. If we (for the purposes of argument) associate ‘exploit’ writing with attacks, and ‘vuln checks’ with defence, then this premise is backed up by the empirical observation that an attacker only needs to be succesful once, whereas a defender needs to be successful *all* the time to avoid security breaches.
Worst use of strategic vs. tactical ever.
I have written both vulnerability checks (ISS, Network Associates (and some private Nessus checks)) and exploits. While they are different, I wouldn’t go as far as to say that they are different skillsets. They are two approaches to the determining whether or not a vulnerability checks. When written by professionals, the goal is do it in a way in which no one noticed that the test ever happened. Crashing a service, or triggering an IDS alert is probably bad whether you are a vulnerability scanner or an attacker. In some cases, I think writing good vulnerability tests can be harder than writing a good exploit. In others, exploits are harder. I think in the case of one-shot exploits, vulnerability tests that do not involve banner grabbing (which should almost certainly NEVER be used), can be incredibly difficult to write.
Finally, with products like ever-Cool Core Impact and Immunity’s CANVAS, the lines between vulnerability test and exploit is blurred. They are all a pain in the ass to write, and I am glad I don’t do either professionally.
3 Comments
Thomas Ptacek | April 27th, 2006 | Filed Under: Bitching About Protocols, Defenses
I *heart* Meebo, which is a free AJAX-style, browser-based client
for AIM, MSN, Yahoo, AIM, GTalk, and AIM. I have no actual complaints about
the service, which is my lifeline to the outside world when I’m on
web-only networks and need help from the team.
So I’m going to complain about it.
Apparently people are concerned about the security of their IM’s. I gather
this because Meebo has taken to reassuring its users that it keeps their IM
logins secure, using “1024 bit RSA keys”.
Unfortunately, this does not mean SSL. SSL for AJAX-style apps is “slow”,
because for any one HTTP hit a Web 1.0 app makes, a Web 3.0 app makes
9,883,103. All of them have to be over HTTPS. Because of security.
So what Meebo does is, they implement RSA in Javascript, and have the
browser “manually” encrypt the IM login before sending it back.
Which is to say, what Meebo does is, nothing.
We don’t even need to get into the details of trusting whatever key the
browser thinks is coming from Meebo’s site, and how public key encryption
is not as simple as transmitting a public key and then just using it.
Because you’re not retrieving that login page over a trusted channel.
What RSA ostensibly does is, the bad guys can’t sniff logins out of traffic.
Ok, they can’t. But they can sniff TCP sequence numbers, and they can send
TCP packets, and the same attacker that RSA addresses can completely replace
Meebo’s secure login with an insecure version of same, minus the encryption.
Does RSA hurt anything here? No. But is there a serious threat model that
it helps with? No. Meebo actually provides an https login, which is great
(though frankly, when I get https hiccups, I just say “fuck it” and log
in “insecurely”. It’s just AIM, and it’s all going to OSCAR anyways).
Security is hard, mmkay?
9 Comments
Thomas Ptacek | April 27th, 2006 | Filed Under: Defenses, Uncategorized
That was fast. Colin takes me to task, and I’ll summarize and respond.
First, two places I was wrong. I said Colin cribbed his work from DJB’s
cache timing paper, which is a remote attack against AES based on S-box
table lookup. Colin also posted his paper months after Osvik and Tromer
published what is now “Cache Attacks and Countermeasures: the Case of AES”.
Colin didn’t cite. But it’s wrong of me to suggest that work that Colin did
concurrently and independently of DJB and Osvik et al was purely derivative.
Colin also calls me out on refering to data-independence, rather than
data-obliviousness. A data-oblivious implementation of AES is designed
so that memory access occurs “completely oblivious” to the data
passing through the cipher. From Osvik et al: You can read the whole
table and select out the result you need, or you can randomize memory
accesses, or shuffle the S-box tables on each access. You can also decrease
signal by generating spurious memory accesses. This was my mistake, and it
happened because Colin knows much, much more about crypto than I do.
The rest of Colin’s critique, eh, not so much:
Colin seems apalled that I suggested he had worked to promote himself.
Here are some things that set me off:
Cajoling OS developers into disabling an extremely useful feature
in the interest of partially mitigating an attack that, for almost
all users, will never occur.
Monopolizing attention on timing attacks for a localhost attack
despite the existence of a plausible remote timing attack for
which Colin’s suggested OS changes do nothing to address.
Insinuating that, as a result of writing the third
paper in as many months on Intel cache timing attacks, Intel was
now trying to get him, and then accusing anyone who criticized
him of secretly working for Intel.
Picking a fight with Linus Torvalds, the “dictator” who declined
to mainline Colin’s suggestion despite the fact that the
overwhelming majority of kernel traffic posters agreed that disabling
HT was crazy talk.
Publicizing an “advisory” for a general crypto practical finding,
unlike any of the other researchers in this field, and then berating
OS developers who questioned him.
Maybe I’m wrong, and Colin really did foresake gainful employment in order to
save the world from Hyperthreading Timing Attacks. But Colin hasn’t yet
supported that claim with evidence.
Colin is irritated that I suggest that there are other serious localhost
timing channels. “But none of those attacks are MINE!”, he seems to be
asserting. Colin repeatedly asserts that the bandwidth of his timing attack
makes it qualitatively different from other attacks. But Osvik et al, which
is clearly the more authoritative work, disagrees:
We have demonstrated the attack […] with HyperThreading, but it can
also be performed on other platforms without relying on [SMT]. The
key is for the attacker to find a way to execute its own code midway
through an encryption […] For example, the attacker can predict
RTC or timer interrupts and yield the CPU to the encrypting process
a few cycles before an interrupt [thus allowing the attacker to
regain the CPU immediately after an encryption operation, enabling
them to probe the cache].
Likewise, Colin is annoyed that I suggested he believed the L2 cache was
a viable attack vector. That’s because Colin was forced to give up on having
the OS guard the L2 cache, after a change he made to FreeBSD halved the
peformance of the Core Duo. But again, Colin’s the only member of this
consensus; from Osvik et al:
On multi-core processors, the lowest-level caches (L1 and sometimes
L2) are usually private to each core, but if the cryptographic code
occasionally exceeds these private caches and reaches caches that are
shared among the cores (L2 or L3), the asynchronous attack becomes
applicable.
Freely conceded that both DJB and the Osvik, Tromer, Shamir team think
HyperThreading should be disabled. Pace Colin himself, they clearly don’t
understand the problem, but in their defence, they’re not OS guys. Maybe
some developers who do understand real-world deployment scenarios will
talk some sense into them. The overwhelming majority of computers, both
servers and clients, are not impacted by this attack. That will change
as virtualized shared servers become the norm, but by then, OpenSSL will
have changed too.
My real issue here is not that I think Colin hasn’t accomplished
anything. As I think I’ve demonstrated, I’m not qualified to challenge
his crypto results, and while Osvik and Tromer’s “Prime and Probe”
technique seems to presage 80% of Colin’s own paper, he has clearly
done important work extending it to RSA.
My problem is that Colin is the “Security Officer” for FreeBSD, and he’s
wasting his time disabling useful architecture features on a platform
that probably allows unprivileged localhost attackers to read the memory
out of any process anyways. Any localhost kernel or privilege escalation
finding Colin published would be more impactful than his Hyperthreading
Windmill Tilting.
Your thoughts, Colin?
5 Comments
Thomas Ptacek | April 27th, 2006 | Filed Under: Defenses
This is funny. From FreeBSD:
Adjust dangerous-shared-cache-detection logic from “all shared data
caches are dangerous” to “a shared L1 data cache is dangerous”.
This is a compromise between paranoia and performance: Unlike the L1
cache, nobody has publicly demonstrated a cryptographic side channel
which exploits the L2 cache — this is harder due to the larger
size, lower bandwidth, and greater associativity — and prohibiting
shared L2 caches turns Intel Core Duo processors into Intel Core
Solo processors.
Because you almost certainly don’t yet see the humor here, let me explain.
Remember Colin Percival? I wrote about him last year. He wrote
a paper, which was actually pretty good, about exploiting Hyperthreading
to snoop keys across process boundaries on multiuser systems.
The refresher course on this attack:
An HT process gives the appearance of multiple execution cores without
actually duplicating all the resources in the CPU. In particular:
- Each “logical processor” has its own IP and register map
- Logical processors share cache, GPRs, and execution units
Read more about HT/SMT at Ars.
Anyways, Colin noticed that “multiple threads, same cache” creates a problem.
While you obviously can’t just pull another hardware thread’s data out of
the L1 cache, you can get a lot of information about the offsets in memory
that another thread is using, and the timing of those accesses. That’s because
each time a thread accesses memory, it potentially evicts a cache line,
which makes the next attempt to access the memory that used to be in the cache
slower.
So Colin writes a tight loop that accesses memory offsets to probe each
cache line, timing each access with the cycle counter. When the latency of
one of those probes jumps, he knows the other hardware thread has hit a specific
cache line. By remembering the cache lines and the order they light up, he
reconstructs a cache “footprint” of the other thread. A lot of detailed
low-level analysis of OpenSSL ensues, and he recovers RSA key bits.
It’s clever. It’s a real attack. And while Colin cribbed it directly
from Dan Bernstein, he “extended” it to SMT and did a lot of
practical work to demonstrate it against OpenSSL RSA, making him
Mitnick to DJB’s RTM. Credit where due.
I’d be a Colin fan, except that Colin went on a blitz of self-promotion,
picking a fight with Linus, accusing skeptics of working for Intel, and
recording “vendor responses”, as if the next generation of identity thieves
were chomping at the bit to get his cache graphing warez. Lost in the commotion
is the simple fact that there are lots of easy timing side channels if you
can run code on the same host as your target. For instance, you can run
‘ps’ in a tight loop and reconstruct ssh passwords. Of course, Colin
says, the SMT attack is “qualitatively” different, because it’s much faster
than any known alternative. But to a skilled attacker, the difference is
one of minutes, not hours. In other words, irrelevant.
Anyways, Colin’s the FreeBSD Security Officer now. He has a blog, too!
Please don’t rush to donate money to him yet, though (even though he
graciously foresook taking employment so that he could get the word out on
the seriousness of his discovery!). Despite the fact that for a side-channel
crypto attacker, localhost access was already gameover, Colin convinced
the FreeBSD project to disable HT by default. Go FreeBSD!
The funny bit is, the FreeBSD kernel code to check and disable HT doesn’t
trust the CPU’s indicator for HT. Apparently some CPUs lie about it. Instead,
the HT knob checks to see if cores share caches, and uses that to infer the
presence of Colin’s Very Serious Threat, and then slows the whole computer down
to evade it.
Wait, that wasn’t funny. Here’s the funny bit: the Intel Core Duo has a shared
L2 cache (but doesn’t share L1 caches). So Colin’s Very Important Knob (ew),
well, go re-read the quote. But Colin, your paper says L2 cache attacks are
“potentially interesting” too; don’t back down now, the Core Duo is evil!
Again, some context: Colin cribbed this attack from a paper that demonstrates
a cache timing attack that works remote. And the likelihood that the
project that Colin is security officer for is shipping code with remote code
exec vulnerabilities, or kernel flaws that will allow an unprivileged process
to simply dump the fucking memory from any process that dares to load up
memory with something that looks like a PKCS identifier, is pretty much
absolute.
Timing attacks are real. And bad. And I still predict we’re going to see them
weaponized in the near future. Maybe even via shared L1 cache surveillance.
But Colin made a bad call. The real effort that needs to be made to resolve
the side channel problem is to pursue crypto with data-independent timing. But
that’s hard, and thankless. Perversely, scrubbing extremely valuable features
out of an entire architecture is neither. So guess which one happens.
1 Comment
Thomas Ptacek | April 19th, 2006 | Filed Under: Bitching About Protocols, Development, Matasano
1 INT. COFFEE SHOP - MORNING
A normal Denny’s, Spires-like coffee shop in New York, with THOMAS
PTACEK, DAVE GOLDSMITH, JEREMY RAUCH, DINO DAI ZOVI, and RUSSELL
HOUSLEY. Dino Dai Zovi has a slight working-class English accent and,
like his fellow countryman, smokes cigarettes like they’re going out
of style. Russell is the primary author of RFC2459. Dave doesn’t eat
meat. Their dialogue is to be said in a rapid-pace, “HIS GIRL FRIDAY”
fashion.
JEREMY RAUCH
No, forget it, it’s too risky. I’m through doin’ that shit.
THOMAS PTACEK
You always say that. But we’re going to need to test TLS negotiation to
finish an assessment of a STARTTLS-capable mail server.
DAVE GOLDSMITH
What’s so hard about that?
DINO DAI ZOVI
TLS means X.509 certificates. DER encoded.
THOMAS PTACEK
Have you read the fucking spec for this stuff? What the hell is the
difference between an IMPLICIT and an EXPLICIT tag?
RUSSELL HOUSLEY
The sequence TBSCertificate contains information associated with the
subject of the certificate and the CA who issued it.
DAVE GOLDSMITH
“TBSCertificate” ain’t no country I know! They speak English there?
RUSSELL HOUSLEY
Every TBSCertificate contains the names of the subject and issuer, a
public key associated with the subject, a validity period, a version
number, and a serial number; some may contain optional unique
identifier fields.
DAVE GOLDMSMITH
Say “TBSCertificate” again! C’mon, say it. I dare ya. I double dare ya
motherfucker, say “TBSCertificate” one more goddamn time.
RUSSELL HOUSLEY
A TBSCertificate may also include extensions.
Dave shoots Russell Housley
THOMAS PTACEK
I still don’t have an answer to my question. What the fuck does “EXPLICIT”
and “IMPLICIT” tagging mean? In a second I’m going to start writing
shell scripts to figure this out.
JEREMY RAUCH
When you go on about shell scripts, you know what you sound like?
THOMAS PTACEK
I sound like a sensible fucking man, is what I sound like. Unix is a programming
language.
JEREMY RAUCH
You sound like a duck. Quack quack quack quack quack quack.
DAVE GOLDSMITH
DOS batch files are a programming language too.
DINO DAI ZOVI
I had a dream last night. I was being chased by one of your shell script
fuzzers.
JEREMY RAUCH
“This Old Vulnerability: SUID Shell Scripts!”
THOMAS PTACEK
I have a better idea than writing a shell script.
JEREMY RAUCH
Writing it in Perl?
THOMAS PTACEK
Fuck you. I’m writing a program to write shell scripts to write X.509
certificates for me —
DINO DAI ZOVI
How is that a better idea than writing a shell script?
THOMAS PTACEK
— it’ll read a binary ASN.1 message on standard input and write a
shell script representation of that ASN.1 on standard output. You can
run the shell script to regenerate the ASN.1 message —
DINO DAI ZOVI
Or regenerate your hard drive if any of the fields contain a backtick.
THOMAS PTACEK
— so input like this:
30 81 9f 30 0d 06 09 2a 86 48 86 f7 0d 01 01 01 \
05 00 03 81 8d 00 30 81 89 02 81 81 00 cf 9a de \
64 8a da c8 33 20 a9 d7 83 31 19 54 b2 9a 85 a7 \
a1 b7 75 33 b6 a9 ac 84 24 b3 de db 7d 85 2d 96 \
65 e5 3f 72 95 24 9f 28 68 ca 4f db 44 1c 3e 60 \
12 8a dd 26 a5 eb ff 0b 5e d4 88 38 49 2a 6e 5b \
bf 12 37 47 bd 05 6b bc db f3 ee e4 11 8e 41 68 \
7c 61 13 d7 42 c8 80 be 36 8f dc 08 8b 4f ac a4 \
e2 76 0c c9 63 6c 49 58 93 ed cc aa dc 25 3b 0a \
60 3f 8b 54 3a c3 4d 31 e7 94 a4 44 fd 02 03 01 \
00 01
DAVE GOLDSMITH
How is Tom speaking in hexdump?
THOMAS PTACEK
— produces output like this:
( ( bkb asn1 oid 1.2.840.113549.1.1.1;
echo -n | bkb asn1 null; ) | bkb asn1 sequence;
bkb binhex 0030818444fd0203010001 | bkb asn1 bitstring ;
) | bkb asn1 sequence;
DAVE GOLDSMITH
And, uh, why is that useful?
THOMAS PTACEK
It works with any ASN.1 BER/DER message. X.509, SNMP, LDAP. Raw messages
directly to fuzzing templates! We are so funded now!
DAVE GOLDSMITH
Fuzzing template?
THOMAS PTACEK
Edit the shell script. “bkb asn1 oid 1.2.840
c 10000 .1
“. Or
“bkb asn1 -L 0xFFFFFFFE” to set the length negative.
DINO DAI ZOVI
And for a realistic X.509 message, it only takes 5 minutes to run the script!
THOMAS PTACEK
Meh, 10 seconds or so.
JEREMY RAUCH
So pretty much the opposite of BreakingPoint Systems there.
THOMAS PTACEK
Yeah. But old school.
JEREMY RAUCH
Just like your web design skills.
NARRATOR
Matasano Blackbag 0.8, Now With “unasn”: Shell Script ASN.1 Fuzzing From
Raw Messages, When You Care Enough To Send The Very Worst. All this
and more, when Thomas Ptacek gets around to copying the tarball up.
10 Comments
Thomas Ptacek | April 19th, 2006 | Filed Under: Uncategorized
On the one hand, I’m a bit irked that Bejtlich let the cat out
of the bag on SYMC’s C&C Music Factory-themed anthem (they got
the sweet solutions!) — it was such a fun way to taunt @stakers
when the didn’t see it coming.
On the other hand, I didn’t know about CHKP’s new-age stylings.
So it’s a wash.
No Comments
Thomas Ptacek | April 17th, 2006 | Filed Under: Defenses
Via Halvar (He’s posting! Maybe the blogroll’s working!):
Setting out to break a significant crypto algorithm could very easily
lead to “10+ years in the wilderness and a botched academic career
due to a lack of publications”. The result: If you haven’t earned tenure
yet, and want to work in crypto, you work on the constructive side.
And via sci.crypt (and David Wagner in particular), a fun thread:
Not a good choice. If Hash() produces n-bit outputs, there is an
attack that requires only 2^{n/3} time… [my edit]
… I concur with the recommendation expressed elsewhere in this
thread: you need a lot of experience in hash function cryptanalysis
before you are qualified to design new hash functions.
No Comments
Thomas Ptacek | April 15th, 2006 | Filed Under: Industry Punditry, Uncategorized
Let’s play “trade press column… or data sheet copy?”
Threat Control - As an application-aware platform, the Secure LAN
Controller protects against both known and unknown threats,
providing more accurate detection than security tools operating at
lower layers, with blocking at a finer level of granularity.
Is it from a column? Or is it from a marketing data sheet? You decide! Either
way, I challenge the writer to prove that they know what these words mean.
Here’s another one:
In cases like this, the only real way to assure protection is with
additional security and monitoring hardware such as a wireless
intrusion detection and prevention system. Such systems can monitor
the airwaves for these types of attacks, and they do not suffer from
vulnerabilities as your wireless infrastructure may. In addition to
being able to alert you to an attack, these systems can also take
preventative action to shield and contain the attack. In the case of
the Aironet DoS, the IPS can detect the ARP storm, then
de-authenticate and tar-pit the attacker.
Risks to your wireless APs mean you should buy special wireless IPS.
Column or data sheet? You be the judge.
5 Comments
Dave G. | April 13th, 2006 | Filed Under: This Old Vulnerability
I am quite positive that when this vulnerability reached Sun, someone’s
head exploded. Unravelling from the core of the vulnerability, we had
a botched fix to a seemingly local automountd vulnerability.
The problem?
The ability to execute arbitrary commands via a supposed RPC call that trickled user supplied data to a popen().
Why was it local?
Because automountd doesn’t listen on any TCP or UDP. But it could accept packets via the Transport Layer Interface(TLI) API.
The fix?
Replace popen() with execve().
The problem with the fix?
The RPC call in question didn’t just let you set command line arguments, but also the command itself. OOPS!
So another 1999 Solaris local… how does this get remote?
Glad you asked… Enter statd! Turns out that via SM_MON and SM_NOTIFY RPC requests, you can forward arbitrary RPC requests to arbitrary RPC services. Not only that, it was capable of using TLI as a transport mechanism.
Wow! Let me get this straight… I send a couple of packets to statd (which was listening on multiple port and protocols remotely) and I can execute a command of my choosing on a remote Solaris 2.5 -> 2.7 machine?
Almost. It turns out that on Solaris 2.6 and 2.7, you also had to slide
past a call to SMHASH(). Let’s look at this amazingly complete explanation of the bounce vulnerability, we see:
Because of the way SMHASH works and the way RPC arguments are encoded, our command is what SMHASH attempts to lookup in its address tables once rpc.statd receives our packet. If SMHASH cannot detect if our command is a valid address, it will not forward the packet.
How do you get around that?
You needed to be able to control/spoof DNS, so that your DNS entry matched the command you were trying to execute. How’s that for badass?
The exploit (minus the DNS stuff), is located here.
In short, combining a botched patch, with TCP/UDP -> TLI protocol traversal and maybe some DNS spoofing, and you are root. It’s just that simple!
5 Comments
Dave G. | April 11th, 2006 | Filed Under: Industry Punditry
While trolling various security product websites, I noticed that several had issued press releases that: “Gartner Thinks We’re Cool”. This brings up an important question. What is the analytical process for determining whether or not a company is cool? Yet again, I call on the securitymetrics cabal to quantify another critical business metric. Unfortunately, from what I have read about cool, it appears that we will need to wear sunglasses in order to qualify for this prestigious title. Thanks to an anonymous source, we have received a copy of the quadrant chart used to categorize cool companies:
7 Comments
