Archive for May, 2006
Dave G. | May 25th, 2006 | Filed Under: Reversing
UndoDB: a debugger that runs C/C++ code bidirectionally. Forwards and backwards. Backwards and forwards. Please dont be a hoax.
UndoDB uses the ubiquitous gdb as its front-end […] gdb has been complemented with a few new commands which work just like gdb’s existing commands, only they step the program backwards in time, rather than forwards. […] UndoDB also compliments gdb’s next, until, finish, stepi and nexti commands with their backwards counterparts: bnext, buntil, bfinish, bstepi and bnexti, respectively.
My plan: run this on itself and cause a rift in the space-time continuum.
8 Comments
Dave G. | May 24th, 2006 | Filed Under: Slashdot Rounddown
The standards blog has a quick piece on how the latest word 0 day is ‘Dan’s [time] bomb Goes Off.
As it happens, Dan’s bomb went off a few days ago, with the breakout of the “Backdoor.Ginwui” virus, a malicious bit of code that Symantec introduced in an alert as follows:
It has been reported that Backdoor.Ginwui may be dropped by a malicious Word document exploiting an undocumented vulnerability in Microsoft Word. This malicious Word document is currently detected as Trojan.Mdropper.H.
Well, lets see what Symantec has to say about Trojan.Mdropper.H:
Threat Assessment
Wild
Number of infections: 0 - 49
Number of sites: 0 - 2
Geographical distribution: Low
Threat containment: Easy
Removal: Easy
Threat Metrics
Wild: Low
Damage: Low
Distribution: Low
Methinks this isn’t the best example of the effects of a monoculture. At least not yet.
1 Comment
Dave G. | May 22nd, 2006 | Filed Under: Disclosure
CERIAS has a blog post on Vulnerability Reporting For The Brave, which based on the title alone already had me ready to pick it apart line by line.
Not today! It turns out that it is targetted towards students who find vulnerabilities in production websites. Unfortunately for researchers, the process of finding vulnerabilities on someone else’s website deployment is similar enough to the process of breaking into it. It is definitely not worth it, and has lead to several people getting in trouble with the law.
In the author’s story, he basically talks about how one of his students found a vulnerability in an application that was broken into by someone else (allegedly ;)). The detectives decided that this student became a suspect. This is definitely a less spoken risk about doing free penetration testing. You will show up in the logs and look no different from some bozo who decides to boldly attack a website. And you will look like a suspect if this happens.
In a way, it’s a shame. One of the factors I use when determining the security quality of an application is by the vulnerabilities reported in it. That doesn’t work so well for Google or Yahoo.
On the other hand, playing with other people’s live data is just a bad idea.
No Comments
Dave G. | May 22nd, 2006 | Filed Under: Industry Punditry
From CNN:
The analyst took the data home without authorization, Nicholson said. Department spokesman Matt Burns said the employee has been put on administrative leave while the investigation is conducted.
What I want is the really good reason why he took those records home. Or how it didn’t go into an immediate firing.
Nicholson said the theft is “disturbing,” but that there is no immediate reason for veterans to believe “anything unsavory is going on.”
Unless you consider that someone stole 26.5 million records unsavory. While in all likelihood this information is long gone, if it wasn’t, it is certainly being used for something unsavory as of today.
No Comments
Dave G. | May 22nd, 2006 | Filed Under: Industry Punditry
Rob Lemos has a story about Blue Security. My favorite part:
It’s uncertain what exactly happened to Blue Security’s site. The IP address for the Web site comes from a block owned by Alternet, which is a backbone network run by the former UUNet, bought by telecommunications company MCI Worldcom, and–as of February 2005–a part of Verizon. However, a representative of the telecommunications company said that Blue Security is not a customer and none of Verizon’s administrators would filter out traffic–known as blackholing–to a Web site.
I love it when people make authoratative statements that they can’t possibly back up. No one would filter out traffic to a website. Inconceivable! I am not saying that it was a Verizon administrator, but if it wasn’t, and it was inside of Verizon (I have no idea if this is true), then who was it?
That is the part of the story I want to hear about.
1 Comment
Dave G. | May 19th, 2006 | Filed Under: Navel Gazing
Hackers try to rig ugly-dog contest
“We’ve been putting in some firewalls or whatever they’re called to prevent the vote stealing from happening again,” Tesconi said. “We want to make sure everybody has a fair shake.”
No Comments
Thomas Ptacek | May 19th, 2006 | Filed Under: Defenses
A proposed amendment to UK criminal law:
(1) A person is guilty of an offence if he makes, adapts, supplies,
or offers to supply any article—
(a) intending it to be used to commit, or to assist in the commission
of, an offence under section 1 or 3; or
(b) believing that it is likely to be so used
I am clearly not a lawyer. And, I concede that this is a poorly worded
law. And, I’m not a believer in criminalizing malware. If you are not
prepared to accept these three statements, stop reading here.
Still with me? Great.
There are three ways to read this:
The government wants to criminalize the distribution of tools designed
specifically to enable people to break the law. Example: credit-card
sniffing bot programs should be illegal.
The government wants to assert an unprecedented new level of control
over the way computers are used, in order to simplify the operational
challenges of law enforcement. Example: encryption programs should
be illegal.
The government, in mortal terror of all things technological, owing
to the fact that lawmakers don’t even read Slashdot, is mindlessly
lashing out at a threat it doesn’t understand. Example: programming
languages should be illegal.
I come down on (1). I am deeply ambivalent about this aim. But I buy
that reasonable people could disagree about a law like this. From Saul Alinsky
(who I really think indie startup geeks should read before Guy
Kawasaki):
Communication for persuasion, as in negotiation, is more than entering
the area of another person’s experience. It is getting a fix on his main
value or goal and holding your course on that target.
So, as a thought experiment, in the wake of Blue Security, try this: what
would you think about this law if the wording were tighter and the “offence”
involved was specifically spam?
Maybe you’re still dead-set against it. I might be too! But there’s a
rational conversation to be had here.
Let’s see where Slashdot comes down on it:
Equally, almost every hacker who commits an offense under section 1
or section 3 of the CMA will use Perl as part of their
toolkit. […] Locking Larry up is surely not desirable.’
Wow. They’re trying to outlaw Perl. I might actually be for this law!
So clearly this Slashdot summary is crazy-talk. You could substitute
the word “computer” for “Perl” here and the assertion would have
exactly the same meaning. I’ll bet the +4 comments will set things
straight:
Heck, peel away all the layers of this onion and it wouldn’t be
surprising to find hackers are behind this [here I stopped reading]
If you replace the software with guns, you will begin to understand
[here I stopped reading]
This sort of news is great for nations like India, Singapore and
Malaysia. The more the Western world places [here I stopped reading]
They will criminalize Python first, because Python has more powerful
event-based socket primitives than Perl
I’m certainly not going to let anything as silly as some U.K. law
stop me from distributing Nmap, but I also don’t want to become like
Dmitry Skylarov [here I stopped reading]
WTF are you talking about? Python doesn’t even have proper closures!
Here is my problem: “peel away the layers of this onion” and the only argument
that the peanut gallery is really making is, “these guys don’t know enough
about computers to write this law”. Well, that’s not a very strong argument,
and it doesn’t make for a very interesting discussion. The real question
should be, “is it a good idea for us to try to fight computer crime by
attacking the supply chain of truly malicious tools?”.
If you get past that saying, “maybe”, then your next question is “how
would you safely write such a restriction into law?”. Thinking of the
law like a programming language: does “sell or offer to sell” do-what-we-mean
better than “makes, adapts, supplies, or offers to supply”?
Here’s another problem: “outlawing nmap” doesn’t mean anything. For
example, you’re aware of course that we are actually illegal in the
state of Michigan:
(c) To receive, disrupt, decrypt, transmit, retransmit, acquire,
intercept, or facilitate the receipt, disruption, decryption,
transmission, retransmission, acquisition, or interception of any
telecommunications service without the express authority or actual consent
of the telecommunications service provider.
This horrible, misguided, overreaching law has not stopped Sourcefire and
ISS from selling to the big auto manufacturers.
2 Comments
Dave G. | May 19th, 2006 | Filed Under: Disclosure, Industry Punditry
Ignorance (The Truffle, Foie Gras and Fried Platinum Salad Days)
Vendors can sit here for years. They often boast about their security, even though they have done nothing to assure their products are actually secure. No one has reported vulnerabilities. The other guys look worse.
Inside Management’s Head: “There’s no evidence to support insecurity, therefore we must be INVINCIBLE. And since we are secure, we better let everyone know how secure we are!”
Attention (Why is that dude with the facial tattoos staring at me?)
A natural result of this ignorance is that other people start to notice. Unbreakable, you say? Pundits Pund. Researchers research. The public starts hearing that maybe the vendor aren’t as secure as you think you are. Articles that come out from the press mention security issues as an aside. The last paragraph will have a quote from a security researcher, industry analyst or pundit saying that ‘the sky is falling’. He is perceived by vendor as another crazy person, walking down the street, yelling into his phone that the world is going to end. And it’s a rotary phone.
Inside Management’s Head: “Every company has the occasional security problem! And analyst’s always predict doom and gloom. And what the heck is a security researcher?”
Focus (Why is everyone starting at me?)
Security research starts getting serious. Vulnerabilities start to come out in your products. Researchers start complaining about how bad your software is, and how bad your response to their reports are. Claims of delays, hiding issues, non-responsiveness.
Inside Management’s Head: “We have a serious problem here. Clearly, we need PR/Marketing to make this problem go away.”
Pain (Why am I not wearing pants?)
The bad press starts actually affecting business. Competitor’s start pushing the security button on customers. Customers start pushing the security button on the vendor. It is now officially holding up deals. It is time to fix it.
Inside Management’s Head: Persistent throbbing or pounding pain, with sensitivity to light, sound and movement.
Stay tuned for part 2, where we talk about the trials and tribulations of actually fixing software!
1 Comment
Dave G. | May 17th, 2006 | Filed Under: Industry Punditry
Blue Security announced that it is calling it quits. They are/were an anti-spam company that would use its customer base to strike back against the spammers, by ‘attacking back’. The basic idea (as I understand it) is that they set up a ‘do-not-spam list’. Spammers who spam addresses on that list get attacked back. I guess the hope was that spammers would download that list, and remove people on it, in fear of retribution.
What happened was that they got outmaneuvered by… wait for it… nastier spam (extortion). And DoS attacks. And there is no doubt that it really sucks, when a company trying to do something to help gets clobbered.
What I don’t get is, How did they not see this attack coming? I mean, maybe not the scale of it, but it seems like they were totally unprepared for it!
Of course, the fact that this attack happened and now they are closing up shop do not have to be related. I still don’t know how they were planning on/or if they were making money.
Good entry on Blue Security (and this incident) at wikipedia.
Spam sucks.
1 Comment
Thomas Ptacek | May 17th, 2006 | Filed Under: This Old Vulnerability
It’s a dark and stormy night. Theo relaxes contentedly in the
basement. Idly polishes a cherished stack of Sun IPX’s. Pauses now
and again to berate his developers on ICB.
He has reason to be smug. His team has just finished an audit of the
OpenBSD userland code, establishing for a glorious ten days a factual
basis for OpenBSD’s security boasts and a role for Theo as a lanky,
cave-dwelling Sun King of open source security. In some cases, his
auditors didn’t even use ‘grep’ to find their stack overflows,
meticulously scanning loops by hand to root out vulnerabilities. Such
is OpenBSD’s greatness during this eternally memorable age.
Devil’s work. Idle hands. Theo picks up a project. OpenBSD doesn’t have
kernel threads. Theo doesn’t like threads. Plan9 has an alternative:
true lightweight processes. You fork them like normal processes, but they
can share memory and file descriptors. You create them with the rfork
system call.
Time passes. A year almost to the day. Champion competitive cup-stacker
Danny Dulai (credo: “People with 1 tongue have no idea what they are missing”)
is poking around at OpenBSD. “Isn’t this a security problem, Theo? Theo?
Wake up, Theo. Here, have some free SCSI cards.” Free hardware… Theo
rouses from a malarial stupor.
Panic. Commotion. An advisory. It is a problem: rfork conflicts with
the Unix security model. It gives parent processes control over SUID
child processes. A user runs “passwd”, which assumes superuser creds
to edit the password database. But passwd is working with the user’s
descriptor table, not its own, and as it opens sensitive files, it’s
handing them directly to the user. The kernel checks access at open(),
not on “read()” or “write()”.
The patch is easy (don’t honor SUID when exec is called on a process
that shares a descriptor table). So easy that Linux had it from the start.
A strange anomaly. The Sun King has introduced a vulnerability into OpenBSD.
It will never happen again. Rfork goes on to be such an important part of
the BSD API that calamity ensues when the most popular BSD fails to officially
include it.
Years later, FreeBSD manages to snatch defeat from the jaws of not
working with Theo. Georgi Guninski, of the one legitimate qmail finding,
notices that FreeBSD has added functionality to rfork;
with RFSIGSHARE, FreeBSD rfork also shares signal handlers with the
child process. User aims SIGINT handler into the
environment. Populates the environment with shellcode. Runs “passwd”,
RFSIGSHARE. Delivers SIGINT. “passwd”, running as root, with the
inherited poisoned SIGINT handler, diverts control to the user’s code.
Somewhere in the celestial clouds, an angel chokes, clutches its
throat, breathes its last, and expires.
2 Comments
