Archive for August, 2005
Thomas Ptacek | August 25th, 2005 | Filed Under: Uncategorized
Bejtlich comments
about this eWeek worm synopsis, and cites
this SANS newsletter
advocating for IPS and “security switches”:
Because [these] worms spread over 139/tcp or 445/tcp, [these] ports
that cannot be firewalled without breaking some functionality in
Windows environment. That means that even a single infected laptop
brought inside an enterprise will infect all the other
machines. Multiple intrusion prevention systems, as ubiquitous as
switches, need to become as integral to networks.”
This is a very popular misperception.
It’s true that you can’t filter 139/TCP (NetBIOS SMB) and 445/TCP
(Direct SMB) wholesale on an enterprise network.
It’s true, in the same sense as it’s true that you can’t filter port
80 everywhere on an enterprise network: everyone uses it.
Thing is, everyone doesn’t use it to everyone else. To put it
theoretically: the graph of 445/TCP usage is sparse.
On the other hand, the graph of 445/TCP connection attempts made by a
worm is dense. It has to be: worms scan randomly. They have to: if
they don’t, infected hosts compete with each other and repeatedly scan
the same hosts.
So, on the one hand, you can say that the solution to the worm
propagation problem is to embed logic in every forwarding path on the
network that will sweep traffic for worm signatures (if you’re going
to do that, here’s a great place to start thinking about
how).
On the other hand, instead of committing yourself to the strategy of
making the IP network aware and coupled to every application you use
forever and until secure programming is a solved problem, you could
instead exploit the difference between the sparse graph of real usage
and the dense graph of actual usage: lock down SMB to legitimate pairs
of hosts.
Locking the network down this way is a hard problem to be sure, but
it’s not harder than making the whole network application-aware, which
I think is a stupid goal and contradicts the single most important
architectural goal of IP
networking.
Things you can do to facilitate “connectivity-based lockdown”:
Divide your network into enclaves or zones by geography or
org-chart and worry only about the connectivity between those
zones.
Learn how the network is used normally and use the information
to write and maintain ACLs (my old
employer did this, partially at my
insistence, so note my bias).
Pursue policies that simplify the connectivity graph on your
network, for instance by centralizing storage.
Two things I like about this approach:
It applies generally to applications we understand well and
applications which haven’t been examined closely, and doesn’t
depend on vulnerability research to be successful.
It applies incrementally: the finer-grained your lockdown
policies become, the more tightly contained outbreaks will
become. For many organizations I’ve worked with, containment
of a worm even to a single building on a campus would be a
win. On the other hand, an all-or-nothing retrofit of
instantly-dated app-layer devices is feasable almost nowhere.
2 Comments
Thomas Ptacek | August 25th, 2005 | Filed Under: Uncategorized
Because “purpose of chargen” seems to be the one of the two modal
Google queries landing people here (the other is “zero day”), let me
take a moment to help my hapless search-engine audience.
The purpose of chargen is to test server-to-client network
performance (speed; packet drops, latency, ordering, etc) with
known data.
The purpose of discard is to test client-to-server network
performance in the same manner.
The purpose of echo is to test bidirectional performance (though
when it was widely available, it also did well as a
userland-level “ping” —- which is useful, because kernel pings
are hooked up to interrupt handlers which may still run even when
userland is frozen, and which may perform reasonably even when
userland is under massive load).
And that’s One To Grow On!
No Comments
Thomas Ptacek | August 24th, 2005 | Filed Under: Uncategorized
I’m writing this primarily because I think I’m doing something wrong
and hope someone has a simpler way of doing this, though I am actually
happy with how my technique has turned out.
I’m doing binary protocol reverse engineering work for something that
runs on a TCP port. To set the scene:
I have two legitimate participants of the protocol connected to
each other.
I proxy between the two with a simple plug gateway that dumps the
TCP data running between them.
I inspect the dumps offline, break them into messages, modify
them, and re-inject them to see what happens.
All very straightforward. The tricky part, if you can call it
“tricky”, is in step #3.
With a text-based protocol, playing games with the protocol is simple:
I’ll use netcat and
type or cut-and-paste into a terminal window.
With a binary protocol it’s not as simple. What I’d normally do is cat
a binary file into netcat, which obviously works fine. The trouble is,
this is a real protocol, meaning I have to wait for responses to my
data and formulate messages accordingly. In other words, I need
interactivity.
And here’s where netcat stops being useful; I can’t figure out any
decent way of interactively generating and parsing binary data in
netcat. Two things netcat could do to make it useable in this case:
Have a mode to print hexdumps of received data in real time.
Have a mode that would interpret escapes as hex codes and
generate the appropriate bytes.
I can’t find a version of netcat that does either.
Here’s what I’ve resorted to:
A netcat-sized C program (I call it “telson”) that makes
TCP connections and proxies between it and a UDP port bound
to loopback and prints hexdumps of all data sent and received.
(Why UDP? Because netcat has that unbelievably irrritating
habit of sitting around waiting for a SIGSTOP after it finishes
reading stdin).
An even smaller program that reads standard input and generates
UDP messages to the telson loopback port (I call it
“blit”). Yes, this is basically netcat, but it’s easier to use.
An even smaller program than that which reads pairs of ASCII
digits as hex codes and generates the bytes (I call it
“hexbin”). Yes, this is basically printf(1), but it’s easier to
use.
This is about 120 lines of code (not counting the event loop in
telson, which is basically libevent). Here’s what it enables me to do:
In one window: telson foo:666
In the other: hexbin 01FF01FF | blit
Result in the telson window:
%CONNECTING foo:666
%CONNECTED
%YOU-SAY
00000000 01 FF 01 FF -- -- -- -- |........|
%
%THEY-SAY
00000000 FF AA FF AA -- -- -- -- |........|
%
%DISCONNECTED
Or: dd if=/dev/zero count=4 | blit
Or: dd if=/dev/rand count=4 | blit
Or: c 5000 0x41 | blit
(btw: ‘c’ is my most useful tiny C program ever; guess what it
does).
So like I said, I’m pretty happy with this; I get to use Unix
pipelines to generate interesting traffic interactively (as long as
all I want is to SEE the output from the other side of the connection,
and not actually USE it —- fortunately, this is 80% of the reverse
engineering problem). Pipelines mean I can write tiny little Unix
filters to:
I feel bad about writing code against this problem, though. Like I’m
just too dumb to know how to use the tools I already have.
So I guess my question is, is there a telnet/netcat-like tool, or some
mysterious option to either, that interactively generates binary?
Maybe there’s some weird xterm command.
4 Comments
Thomas Ptacek | August 24th, 2005 | Filed Under: Uncategorized
Here’s Christopher Hitchens citing
the fucking Onion
to make an argument. He’s not being facetious; he “honestly cannot decide
whether [it] is a clever hoax or not”.
Christopher Hitchens is such a fucking tool.
There, I feel better now.
(Read the Onion article though; it’s funny. I’m going to formulate a
faith-based theory of Intelligent Vulnerability Security that will assert
that secure coding is a “theory in crisis” which doesn’t explain the
influence of God in our software development process).
2 Comments
Thomas Ptacek | August 23rd, 2005 | Filed Under: Uncategorized
For the most part (please?), my moving nightmare appears to be over.
I believe I am now a resident of Oak Park, IL, and no longer a resident of
Ann Arbor, MI.
Oak Park is basically Chicago (it’s directly adjacent and connected via the
el train, meaning
that on any given weekend I am one transfer from dim sum.
That, plus the fact that I was born and raised in Chicago, makes the
move a step forward.
Brief thoughts on the move, which is my seventh in eight years:
Renting a 24’ truck is very expensive (well over $500).
Hiring moving labor to load and unload isn’t very expensive (under $200,
each end).
Renting your own truck and hiring labor eliminates the most painful
part of the move and costs less than a quarter of what full-service
movers charge.
So I recommend that strategy.
Renting a car carrier trailer is somewhat expensive (just shy of
$200).
Securing a car to one without professional help (either mechanical
or psychiatric) is difficult.
Driving a 24’ truck with a car carrier at 45mph on the Borman Expressway
is absolutely terrifying.
So I don’t recommend that strategy.
Three things I will miss about Ann Arbor:
Zingermans, which is well worth the money and which I will maintain
going forward as my sole source of artisinal marshmellows.
Angelos, even though the deep fried french toast reminds me of a
Burger King breakfast entree; I’m not sure I’m going to find a
better breakfast place in Chicago.
I’m not sure right now that there is a third thing I’ll miss about
Ann Arbor.
Those who know me well will be happy to know that I’ve sold the car, which,
for those of you who don’t know me, appears to contain that tiki statue from
the Brady Bunch.
I’ll post-mortemize the M3 in a future post, but for now, suffice it to say
that I purchased it three times and owned it twice concurrently.
I have some catching up to do and more stuff to write about. I promise
to spare you the obligatory pictures of the new house. For now, I
recommend you chew on this, which is
the coolest link I’ve followed this week.
No Comments
Thomas Ptacek | August 19th, 2005 | Filed Under: Uncategorized
Just in the middle of moving my house from Ann Arbor to Oak Park, IL, and away from net access.
No Comments
Thomas Ptacek | August 11th, 2005 | Filed Under: Uncategorized
Hey, Thomas, Lindstrom says we can’t name an advisory that originated
with a zero-day exploit!
See?
C’mon, just point me to ONE major vendor patch bulletin that
originated when you saw the vulnerability exploited in the wild
before any good guys knew about it. Presumably, this exploit would
have been the catalyst for discovery and disclosure by the good
guys. I’ll definitely buy you a beer or 50 if you can do that.
Oh-no-he-DIH-int!
Peter, I’m happy with Bass, but if you can find me 50 bottles of
Big Rock Grasshopper, that’d bring back nice
memories of the night I spent reverse-engineering the captured,
“in-the-wild” (gag) tooltalk exploit binary so I could write this advisory.
Want another example? Try rpc.statd,
one of the most widely-distributed pre-disclosure vulnerabilities ever (and
the bane of Sun operators for like 5 years).
3 Comments
Thomas Ptacek | August 10th, 2005 | Filed Under: Uncategorized
From Lindstrom’s latest,
and here only because it’s not directly a full-disclosure
argument. Lindstrom is dubious about researchers who claim to be “in the know”
about secret vulnerabilities:
If you really do know and can’t say, why would you hang the entire
Internet out to dry by keeping in-the-wild exploits against
undercover vulnerabilities a secret while you encourage the wheel
spinning of research and disclosure?
Here are a couple reasons “why”:
You found the hole and are waiting for vendor response
You know the people who found the hole are waiting for vendor response
You know people who were victimized by the hole and that the hole
is part of an active investigation
You know the hole exists but not how to make the exploit work
You know the exploit exists but not the details of the hole it exploits
Your knowledge of the hole is connected with a work-for-hire
situation that attributes ownership of the information to someone
else
Your information about the hole comes from a confidential informant
who will be compromised by your disclosure
Like Lindstrom, you believe that disclosing the hole will do more
harm than good
Having knowledge of vulnerabilities that are not public is, and always has
been, a commonplace among people working in this field. Some of my reasons
(like the “confidential information” thing) sound “cloak and dagger” but
are really pedestrian —- “a friend told me”, and “the only purpose served
by me publishing is that I’ll never get a heads-up from her again”.
Certainly this is one of the ethical conundrums you’d like to see
a real security code of ethics addressing.
Also, as an aside to Lindstrom, you betray a certain mindset
when you refer to exploits as “in the wild”. We don’t work in antivirus,
and I think you’d agree, there’s no such thing as a “dormant” vulnerability.
Updated 2:45P CST
Lindstrom clarifies what he means by “in the wild”. Granting that the distinction he’s making is meaningful,
here’s the issue:
In antivirus, the difference between an “in the wild” virus and a “laboratory” virus is that you care about “in the wild” viruses.
By Lindstrom’s definition, you’d be negligent in any setting, triage or not, if you left vulnerability open on a public-facing resource just because you didn’t know about its “in the wild” implications.
It’s not just that we’re shifting mindsets to antivirus, where the bar for security is much lower than here, where we’re defending Tibco trading transactions for Fortune 10 financial institutions. It’s that antivirus uses the term in a very loaded manner that provokes a certain (somewhat casual) risk response, and I think it’s dangerous to bring that way of thinking into real security.
No Comments
Thomas Ptacek | August 9th, 2005 | Filed Under: Uncategorized
By the way, at some point, someone is going to have to explain to me the
difference between vulnerability research in “normal” software and research
in “cryptographic” software. If you discard vulnerability research and
disclosure (aka “cryptanalysis”) from cryptography, you lose, well, the
whole field of cryptography.
This is self-evident, of course, and it’s the reason Bruce Schneier
urges aspiring cryptographers to go break a published cryptosystem before
they try their hands at designing new ones. It’s much harder, and much
more educational, to break a cryptosystem than to design a crappy new one.
(By the way, this provides the response to Ranum’s demogoguing “it’s
easier to break things than to build them (comma-asshole)” quip. Maybe
it’s easier to break bad things than to build them, but there’s nothing
easy about building or breaking a good thing.)
Clearly Schneier-citing anti-disclosurites see some kind of divide
between the vulnerability research Biham, Shamir, Bernstein, Kocher,
and Schneier himself does, and the kind of research eEye does. I even
buy that the line they’re talking about exists. But where to draw it?
If you end the “legitimate” research at math, you lose “the hardest part
about designing a cryptosystem” (to paraphrase the fantastic Practical Cryptography).
Lots of protocol flaws can be deduced with pen, paper, and a spec, but if you
draw the line at “anything that doesn’t involve source code flaws”, you
miss things like “don’t use S-boxes because they leak timing”.
Sure, most software bugs are simple. Grepping for “strcpy” is less of an
accomplishment than discovering differential cryptanalysis.
You win, crypto geeks. But there are plenty of simple cryptosystem flaws,
too. And there are plenty of very complicated software flaws.
For that matter, it may be easy to write new x86 stack overflow exploits, but
the first one sure as hell
wasn’t; it tooks months after being goaded by 8lgm
to get it down.
I totally buy that this is a line that people like Lindstrom,
Schneier, and Davidson would like to be able to draw. The rule could
be, “disclosures that demonstrate novel vulnerabilities that will
enable us to fix whole classes of problems will be published in
detail, and everything else will be obscured”. I agree. It’d be great
if we could. But we don’t know a lot of things about computer science
(which is why vendors can get away with selling
software
that ignores the Halting
Problem). What are you
gonna do?
Writing about full disclosure is the easiest thing in the world to do for a
security blogger, so every word I write about it feels like cheating. I’m
going to try to stop now.
No Comments
Thomas Ptacek | August 9th, 2005 | Filed Under: Uncategorized
It’s nice of Lindstrom to respond,
particularly because it was nasty for me to lump his post in with Davidson’s
screechy rant (caricature-by-association should be an entry in the Nizkor list.)
Lindstrom says my argument is emotional. Here’s the relevant snippet, regarding
my inability to keep stripped-down BSD totally secure in 1996:
I don’t know what you did wrong, but I suspect you have a couple of
ways to address that problem today - with proxies. In 1996, the risk
was higher, though the ultimate impact was likely lower for most
people. There were fewer people even on the Internet, and of those,
most were technical elites. Tell me again why this matters today? Is
it to evoke some sort of emotional commitment on my part? I don’t
know - things change. Get over it.
I’m not sure what’s emotional about this. It seems simple to me:
It was simply not possible to run a secure mail server in 1996.
It is possible now.
The reason it’s possible is because security “researchers” beat
the living hell out of software in the late 90’s.
(For the record, what I “did wrong” was to operate a server in 1996).
Back in 1996, there were just as many people complaining about
“disclosure management” issues as there are now. Donn Parker compared
the release of SATAN, a tool that finds open file shares, to
“distributing high-powered rocket launchers throughout the world, free
of charge”. The same arguments Lindstrom uses now: that disclosure
serves no purpose, that the evildoers will use vulnerabilities
anyways, all applied and were used back then.
The point is, when you advanced those arguments in 1996, you were dead
wrong. Why are you any more correct now?
Lindstrom says, “things change”. I guess so. Can you support that
statement with evidence?
Lindstrom says, “so, you made Microsoft accede to your demands”. Are
we any better off for it? I don’t know; I don’t go after Microsoft,
and I don’t use Windows. But I’m happier to know that they’ve got
library and OS-level protection against stack and heap overflows now,
and confident that Microsoft customers wouldn’t have had those
protections without disclosure work.
Lindstrom recommends I read “Against the Gods” and learn more about
risk reduction (serendipity: I’ve got a paperback copy on my
desk right now). To show that disclosure helps, he says, we have to
find every single vulnerability that the bad guys find (his
emph). Flawed premise:
In the “risk reduction game of small numbers”, finding a
vulnerability before the Russian Mafia does provides a
measurable reduction in the number of machines that can
be compromised.
The Microsoft-style response of blanket-level protections
preemptively eliminates other as-yet-undiscovered
vulnerabilities; this doesn’t just mean “heap overflow
protection”, but also things like input sanitization and
least-privilege design retrofitting.
The third-party protections Lindstrom advocates, like host
IPS, came in to being as a result of disclosure work; their
deployment is motivated by ongoing disclosure work. For that
matter, you can say the same thing for firewalls. Patching
isn’t the only mitigating response. Services that have a
demonstrated tendency towards failures can be:
And virtually all of these responses preemptively mitigate
vulnerabilities that haven’t yet been discovered; reactions to
disclosure that provide a force-multiplying advantage against future
work by attackers.
The problem here is that:
They can’t ALL be disabled, filtered, profiled, segregated,
proxied, and replaced: securing network software is a triage and
risk management exercise, and the most important elements of the
information that guide that process come from disclosure work.
Without a market for proxies and replacements, proxies and
replacements won’t be designed. In the absence of the ten-year
track record of repeated failure in Sendmail, you don’t get qmail
and Postfix.
My sense of it is that Lindstrom’s argument is that everything should
be proxied or guarded by HIPS. My response is that, for a lower level
of effort and expense, we could deploy line-by-line audited
open-source replacements to every insecure service. It’s an
all-or-nothing argument: either you bite the bullet and spend tens of
millions of dollars per F500 enterprise to fix the security problem, or you
live in the risk-management world of disclosure and response.
No Comments
