Georgi Guninski’s $500

Thomas Ptacek | May 30th, 2005 | Filed Under: Uncategorized

On May 6, Georgi Guninski found an apparently exploitable flaw in qmail. DJB now apparently owes him $500. I am very, very surprised. But I’m also not patching qmail, nor should anyone else.

First, the problem: DJB’s command parser does a strchr() and saves the (size_t) result into a signed integer counter. The result seems to be a textbook integer overflow: for very long strings, the integer counter goes wildly negative and whacks memory outside the array bounds.

(“integer overflow” is a really dumb name for this problem, by the way).

The quick impact analysis, drastically mitigating the attack:

• It only works on LP64.

• You need a huge amount of per-process memory —- more than is allocated to processes on LP64.

• You don’t get any privileges as a result of the attack.

In a nutshell, you have to be on a 64-bit platform, like amd64, and you have to have a genuinely weird system configuration. A ventured guess: nobody is actually vulnerable to this attack.

Having said that, if you’re looking at the code, this is a glaring error. From Dan’s own statement of research goals:

For more than a decade I have been systematically identifying error-prone programming habits —- by reviewing the literature, by analyzing other people’s mistakes, and by analyzing my own habits —- and redesigning my programming environment to eliminate those habits…

And he has. Nobody has ever found a format string attack, a stack overflow, or a file handling race condition in DJB’s code. In 1998, I sat down in Theo de Raadt’s basement with him and Tim Newsham and, over really bad Canadian pizza, read through the qmail code looking for bugs. We found jack shit (although we did come up with a hypothesis that, due to a lack of function prototypes somewhere, you might get a truncated pointer return value exploitable on 128 bit architectures —- I’m sure we were wrong, though).

Until now, nobody has found any meaningful attack against qmail ( Venema’s DOS attack obviously does not count). Despite being one of the most widely-used packages deployed on the Internet (likely still in the top 5 of SMTP MTAs), the last release of qmail was in 1998, 7 years ago. That’s not because DJB isn’t paying attention to qmail; it’s because no meaningful problems have been found. That’s an insanely excellent track record, unmatched by any other package of comparable popularity.

DJB is rejecting the claim on the $500 prize. His logic is sound: it’s probably not possible to exploit this problem anywhere, and certainly not possible to exploit it in any sane configuration. But returning an unsigned, unchecked size value into a signed integer counter is a textbook case of an “error-prone programming habit”. DJB should get to work on a programming environment change to eliminate these problems.

Meanwhile, the criteria for payout of the award (at least, one of the awards ) is as follows:

• Remote exploits that give login access
• Local or remote exploits that grant root privileges
• Local or remote exploits that grant read or write access to a file the user can’t normally access because of Unix access controls (owner/group/mode)
• Local or remote exploits that cause any of the long-lived qmail processes (currently: qmail-send, qmail-rspawn, qmail-lspawn, or qmail-clean) to terminate.

I say this qualifies. Other people seem to disagree (though this jackass seems not only to agree but also to see this as an opportunity to repeat the qmail blood libel that a package with freely available source code and a thriving community of modifications doesn’t qualify as open source).

Sure, you don’t get enhanced privileges —- in fact, one of the things that’s so impressive about the qmail code is that despite the well-deserved reputation the code has gained for bulletproofing, the architecture still anticipates flaws —- but that doesn’t matter. The ability for a remote attacker to execute arbitrary system calls on a compromised host is a game-over condition in practical security.

So, despite the obvious impracticality of this attack, if nobody is going to cough up the $500 reward, or explain to me in terms beyond “nobody is going to wind up in a vulnerable configuration” why this isn’t an actual flaw, I’m probably going to pay up myself. I really don’t want to do this. Maybe four other like-minded people would be willing to split the prize liability with me, or maybe somebody smarter than I am will talk me down.

No Comments

Schneier on Kumar, Paxson paper

Thomas Ptacek | May 27th, 2005 | Filed Under: Uncategorized

Schneier comments on Kumar and Paxson’s excellent paper. ” They also believe that the attack was, at least in part, a deliberate cyber-attack on the U.S. military; an army base was deliberately targeted in the worm’s hotlist.” All due respect, Schneier, but I don’t think that conclusion is supported by the paper (though with a Nicholas Weaver co-credit, you can’t really tell for sure).

Really, the only thing the authors can point out is that a .mil /16 was specifically targeted; there are other reasons to target military bases than wanting to “cyber-attack” the U.S. military —- like, for instance, the fact that military installations are well-documented ISS customers and thus more likely to have infectable hosts.

No Comments

Tracing Back a Zero-Day Worm

Thomas Ptacek | May 25th, 2005 | Filed Under: Uncategorized

This is impressive detective work, though par for the course for Vern Paxson’s teams. Kumar and Paxson pick apart the Witty worm and, using a network telescope, break the random number generator used by the worm to trace its progress across the Internet.

Coolest finding: among the packets captured from “typical” infectees, they found a standout source that appears to have used a different random number generator. It’s highly probable that this machine wasn’t a normal infection at all, but rather the “patient zero” host the worm authors used to kick-start infections. FWIW, patient zero seems to have been a European ISP address. Other findings:

• When you can reconstitute the sequence of random numbers used by an infectee, you can estimate the rate at which it scanned the internet by comparing two observed packets from the infectee and working out the length of the random number sequence between them.
• By being overly clever with the random number generator, Witty’s author managed to miss 10% of infectable hosts.

Math is the new string search; these results are more clever than most of the tricks “deep packet” security tools use (though Stefan Savage’ signature synthesis work is extremely clever too —- but it too is more math-y than string-y).

Paxson’s team also has a paper up on reliable TCP reconstruction, a topic close to my heart, so I guess I’m going to lose another 30 minutes of working time. Sorry, Jeremy.

[more security]

No Comments

10 Second Record Review: Decemberists — Picaresque

Thomas Ptacek | May 24th, 2005 | Filed Under: Uncategorized

Arr, 90 Sea Chantees on 3 compact disks. Act now and get a bonus CD: Hornpipe Fever. Arr!

No Comments

A quick SOX cheat-sheet

Thomas Ptacek | May 24th, 2005 | Filed Under: Uncategorized

I wrote this up in an hour to help write a white paper for a security product. It may be inaccurate, wrong, stupid, or insulting. See fullpost for details.

SOX Cheat Sheet

• 302: Execs go to jail if the report is fucked up
• 404: Create reports on controls, gotta use an accepted framework
• PCAOB: The gov’t group that oversees SOX
• COSO: The (business) auditor standards body/document
• COBIT: The (IT) auditor standards framework COSO recommends

COBIT Breakdown:

• Planning
• Acquisition
• Delivery
• Monitoring

P1.0 Defined a Strategic IT Plan

Short-range, long-range, changes to plan, report the plan, monitor plan, assess existing systems

P2.0 Define the Information Architecture

Have a model, a syntax, classification, and security levels

P3.0 Determine Technological Direction

Planning, tech trends, contingencies, acquisition plans and standards

P4.0 Define the IT Organization and Relationships

• 1 IT Planning or Steering Comittee
• 2 Organizational Placement of IT
• 3 Review of Organizational Achievements
• 4 Roles and Responsibilities
• 5 Responsibility for QA
• 6 Responsibility for Logical and Physical Security
• 7 Ownership and Custodianship
• 8 Data and System Ownership
• 9 Supervision
• 10 Segregation of Duties
• 11 IT Staffing
• 12 Job Descriptions for IT Staff
• 13 Key IT Personnel
• 14 Contracted Staff Policies
• 15 Relationships

P5.0 Manage the IT Investment

Budget, cost-benefit

P6.0 Communicate Management Aims and Direction

Management responisibilities, policies, maintain policies, security framework policies, IPR, IT security awareness

P7.0 Manage Human Resources

Recruit & promote, qualifications, training, clearance, job change & termination.

P8.0 Ensure Compliance with External Requirements

Identify other regs, privacy, intellectual property, commerce, etc.

P9.0 Assess Risks

• 1 Business Risk Assessment
• 2 Risk Assessment Approach
• 3 Risk Identification
• 4 Risk Measurement
• 5 Risk Action Plan
• 6 Risk Acceptance
• 7 Safeguard Selection
• 8 Risk Assessment Comittee

P10.0 Manage Projects

Project teams, frameworks, approval, test plans

P11.0 Manage Quality

QA assurance planning, review, dev lifecycle, third party implementors, pilot projects, quality metrics

A1.0 Identify Automated Solutions

Requirements, feasability, information architecture, risk analysis, security controls, audit trails, maintenance, facilities

A2.0 Acquire and Maintain Application Software

Design, manage changes, requirements definitions, source data, interfaces, controllability, availability, integrity, testing

A3.0 Acquire and Maintain Technology Infrastructure

Assess, maintain, security, installation, change controls

A4.0 Develop and Maintain Procedures

Training, manuals, documentation

A5.0 Install and Accredit Systems

Train, capacity planning, conversion and migration, testing

A6.0 Manage Changes

• 1 Change Request Initiation and Control
• 2 Impact Assessment
• 3 Control of Changes
• 4 Emergency Changes
• 5 Documentation and Procedures
• 6 Authorised Maintenance
• 7 Software Release Policy
• 8 Distribution of Software

D1.0 Define and Manage Service Levels

SLAs, performance procedures, monitor, report, improve

D2.0 Manage Third-Party Services

• 1 Supplier Interfaces
• 2 Owner Relationships
• 3 Third-Party Contracts
• 4 Third-Party Qualifications
• 5 Outsourcing Contracts
• 6 Continuity of Services
• 7 Security Relationships
• 8 Monitoring

D3.0 Manage Performance and Capacity

Availability, monitoring and reporting, trending, forecasting, usage schedule

D4.0 Ensure Continuous Service

Contiuity framework, plan, requirements, training, identify critical resources, backup sites, backup, etc

D5.0 Ensure Systems Security

• 1 Manage Security Measures
• 2 Identification, Authentication, and Access
• 3 Security of Online Access to Data
• 4 User Account Management
• 5 Management Review of User Accounts
• 6 User Control of User Accounts
• 7 Security Surveillance
• 8 Data Classification
• 9 Central Identification and Access Rights Management
• 10 Violation and Security Activity Reports
• 11 Incident Handling
• 12 Reaccreditation
• 13 Counterparty Trust
• 14 Transaction Authorization
• 15 Non-Repudiation
• 16 Trusted Path
• 17 Protection of Security Functions
• 18 Cryptographic Key Management
• 19 Malicious Software Prevention, Detection, and Correction
• 20 Firewall Architectures and Connections with Public Networks
• 21 Protection of Electronic Value

D6.0 Identify and Allocate Costs

Charging, billing

D7.0 Educate and Train Users

Traning and awareness

D8.0 Assist and Advise Customers

Helpdesk, escalation, trend analysis at helpdesk

D9.0 Manage the Configuration

Configuration record, baseline, status accounting, unauthorized software

D10.0 Manage Problems and Incidents

Management systems, escalation, audit trail (tickets), emegency authorizations

D11.0 Manage Data

Data preperation, authorize, error handling, retention, accuracy, error handling, integrity, output handling and distribution, security for output reports, protect sensitive information during transmission (ala HIPAA EPHI), storage management, backups, archives

D12.0 Manage Facilities

Security, escorts, low-profile, UPS, earthquakes and shit

D13.0 Manage Operations

Job scheduling, logs, documentation, remote operations

M1.0 Monitor the Processess

Collect data, assess performance and satisfaction, report

M2.0 Assess Internal Control Adequacy

Moitor internal controls, on-time deployment, report control levels, report operational security

M3.0 Obtain Independent Assurance

Get independent security people in, conduct audit for IT services and for third-party services

M4.0 Provide for Independent Audit

Audit charter, independence, ethics, competance, planning, reporting, followup.

No Comments

The Death Knell For SOX IT Business?

Thomas Ptacek | May 24th, 2005 | Filed Under: Uncategorized

William Donaldson, chairman of the SEC, expresses concern over “excessive or duplicative effort” by management and outside auditors. An article in the Washington Post presages revisions to the PCAOB guidance regarding rules for auditors for compliance.

Uh-oh. Is this the beginning of the end of multi-million dollar SOX compliance contracts driven by auditors?

Before I continue: the SOX glossary, as I understand it:

SOX: Sarbanes-Oxley Act, sweeping new regulations about public company accounting, including:

Section 404: a required filing detailing what companies are doing to prevent misuse of financial data, and how they had that audited.

COSO: An accounting practices standard defined by the “Big 4” accounting firms; essentially, the “content” of a 404 filing.

COBIT: The IT standards defined by COSO.

PCAOB: The official body that tells auditors (and thus COSO) what to do.

If you’re an infosec person, COBIT is a huge weight around your shoulders right now. COBIT is huge, and has a tendency to spend a single sentence defining major new internal security requirements, such as COBIT P4.10 (“access to resources internally must be segregated by duty”). A good rule, but maybe a bit ambitious for a network that can’t even restrict web consultants from doing SQL queries against the finance server, and just one year ago finished erecting a firewall-based perimeter to keep teenagers from Bulgaria from doing same.

The new PCAOB guidance seems to say that companies don’t need to pay for entirely separate SOX audits, that auditors shouldn’t foist SOX “checklists” on their customers, that auditors should focus first on the most demonstrable risks of accounting fraud, and that audits should be “top-down” and start with company-level issues rather than the individual details of how an IT department encrypts and ACLs individual connections.

So, like I said, “uh-oh”. I got tipped off to this by a friend in infosec at a major company; these announcements were a big deal for him, and he read them as a rebuke to the big 4.

I don’t think it should be hard to motivate people to improve internal security, even without massive regulatory pressure. In fact, I think regulatory pressure has the inverse effect on infosec teams: “checklist” security and paperwork, distracting overburdened teams from doing real work and sapping the credibility of genuinely important initiatives like internal access control (nothing saps tech credibility quite like having your technical work dictated to you by an accountant). On the other hand, many security vendors and service groups count on SOX for a significant chunk of their revenue, and this could be painful for them.

Weird as it sounds (we ARE talking about accounting rules here), I can’t wait to see what happens next.

No Comments

It’s that time again: time for USENET FULL DISCLOSURE DEBATE!

Thomas Ptacek | May 21st, 2005 | Filed Under: Uncategorized

Doug Gwyn: however, the thing to do first is to notify a CERT and let them work on getting existing products fixed before you alert the general public (meaning the attackers).

Doug Gwyn comes to us live from the year 1991. Boy is he going to be pissed when he finds out about Bugtraq.

Colin Percival: all that matters as far as computer security is concerned is fixing the problem in a manner which results in as little risk as possible.

From Wikipedia: Risk is the potential harm that may arise from some present process or from some future event. I guess Robert McHenry was right; it really is a “faith-based encyclopedia”. Better go edit those last 5 words out.

Or maybe Colin’s argument is that there won’t be any more vulnerabilities after his; or maybe that we simply have no influence over them?

Paul Rubin: Designers and implementers doing anything security related generally do their best not to leave holes …

Thanks for playing, Paul.

David Wagner: the best bug-disclosure policy to follow is an optimization problem

So the best response to the discovery of a critical security vulnerability is to get a party who has virtually no concrete information about the extent to which important organizations (banks, military installations, homestarrunner.com) are exposed to a threat together with a party who has virtually no incentive to see their broken software maligned in public, and trust them to “optimize” the disclosure to the benefit of sysadmins everywhere.

Let’s grant the notion that vulnerability disclosure can be optimized to the benefit of the typical sysadmin. Why is this the best possible outcome for us? Isn’t there a better possible outcome wherein organizations who are exposed to vulnerabilities can quickly make the decision to disable the broken software to mitigate their exposure, in advance of a well-tested patch? For example:

Casper Dik: *There’s no proof that the “immediate disclosure” has a stronger effect on the improving software quality than “disclosure at some later time”.

Casper ought to know better. In fact, wait, Casper does know better; he worked in security at Sun when they while they were patient zero in the successive epidemics of integer overflows, race conditions, metacharacter expansions, and buffer overflows. Casper knows that if we installed SunOS 4.1.3U1 from 1995 on a reachable IP address today it would take less than 72 hours for it to be broken into.

Of course, Casper’s not arguing against disclosure —- just “undisciplined” disclosure, like the kind where you don’t sit and wait for 8 months while the vendor beta-tests the patch they come up with. What Casper isn’t acknowledging is that, during the time when his company was making security teams sit on their hands during the 90’s, there was plenty of “undisciplined” disclosure occurring, such as the disclosure of the rpc.statd NFS vulnerability and the ToolTalk vulnerability, which were exploited for years before being announced.

The irony here is, unless you were using ToolTalk (if you haven’t heard of it, you weren’t relying on it) or NFS file locking (even if you have heard of it, you weren’t really relying on it), you were only superficially exposed to these problems: all you had to do was turn the services off.

But the people I’m quoting don’t believe you should be able to make those decisions. Some people were relying on ToolTalk: if we disclosed the vulnerability without making a patch available, they’d could be held liable for not incurring the business cost of disabling the vulnerable service rather than accepting their exposure to a known threat. Best not to force such uncomfortable judgement calls, and let CERT and the vendors make it for them.

Casper continues, “We have no data, just suppositions.” We don’t have data? What have SecurityFocus, X-Force, Bugtraq, and Secunia been doing for the last 7 years? We do so have data: this argument just says you’re too lazy to mine it for evidence to support your conclusion. The real problem is that the data doesn’t support your argument; vulnerability research by groups like eEye and OpenBSD have drastically improved the security of popular software.

Casper is a very smart person. Some of the people participating in this sci.crypt thread aren’t so smart. If it weren’t for participants like Casper and David Wagner, I’d be tempted to believe that none of the posts in this debate come from people who have ever handled a major vulnerability disclosure (no, Paul, elm doesn’t count). What do these people think about the (prevalent) practice of selling vulnerability information to the highest bidder?

No Comments

Gang of forfeit

Thomas Ptacek | May 19th, 2005 | Filed Under: Uncategorized

In my continuing series on being baffled by the popularity of Python (and grudgingly proceeding to select it for every new project I start), I will now pick a nit in “Design Patterns in Python”.

This code:

class Singleton:
    __single = None
    def __init__( self ):
        if Singleton.__single:
            raise Singleton.__single
        Singleton.__single = self

… misses the point of the Singleton pattern. The idea behind Singleton is to make it difficult to accidentally create two of the same Singletons, not to punish you for an accident that is still easy to make.

So far the best Singleton imp I can find in the mailing lists is:

class _Singleton: 
    ...
Singleton = _Singleton()

See how the “real” class has an underscore? See how that means nobody will call it directly? See? Sigh.

No Comments

Schneier & CERT on Insider Threats

Thomas Ptacek | May 18th, 2005 | Filed Under: Uncategorized

Bruce Schneier comments on a CERT study about insider attacks. I agree with him: like every other report stating that damage caused by insiders dwarfs damage caused by internet hackers, this report will be ignored and misses the point. Like Steven Levitt points out in Freakonomics (excellent, read it in one sitting waiting for a plane out of MSP yesterday), white-collar crime is hard to track because we only have numbers on the people who get caught. Most don’t.

I gave a talk on this yesterday for ISSA. I did poorly, but I’ll post slides or something from it later on. I really only have two insights about the internal security threat:

• From a network security perspective, once you get behind perimeter firewalls (ie, to the “internal network”), you’re back to 1993 levels of security. Arrogant scanner developers that we are, we tend to make fun of Dan Farmer’s SATAN scanner for being tame; the fact is, though, that if you switch NFS/RPC to SMB/DCOM, the Dan Farmer approach would tear apart most corporate internal networks.

• From a threat modeling perspective, we think too much about whether employees are going to screw us. Yes, yes, pigs vs. sharks, but if the gaping hole in internal security is self-evident, we need to motivate people, and the employee vector doesn’t seem to be particularly credible. My (emotional, subjective) contribution to the internal threat model discussion:

  • The contractor vector. Someone really, really wants your HR information, source code, sales leads, financial data: she scores a job as a web contractor or data entry tech, and finds herself with wide-open access to every system on the network.

  • The VPN vector. Spent $500,000 on a shiny new firewall rollout? Contrast with the $50 Windows XP system that shares the same logical position in your network defense: an attacker who can find one of your VPN clients can break a desktop machine to get open access to every system on the network.

  • The partner-net vector. From discussions with Fortune 500 security teams, this is a big part of how network worms managed to squeeze into otherwise protected corporate networks (that, and the “walk-in vector” that mobile users with infected laptops create): there’s a graph of connections between corporations, their supply-chain and outsourcing partners with backdoor network connections, and so-forth.

  None of these attacks involve legitimate complicit insiders. Schneier’s point is that the threat from complicit insiders is greater than normally advertised and I think it makes sense that he’s right. But from my perspective, the difference between “insider” and “internet” attacks is about our reliance on a single Internet perimeter; it’s the modern infosec equivalent to the struggle between trench warfare and blitzkrieg. Internet perimeters are fixed fortifications; it’s not stupid to have them (in fact, it’s demonstrably valuable), but it’s definitely stupid to end your defenses there.

No Comments

CPU Caches: Threat or Menace?

Thomas Ptacek | May 18th, 2005 | Filed Under: Defenses, Uncategorized

So Colin Percival presents a paper at BSDCan (which appears to be the Usenix scene’s answer to CanSecWest in which he declares that Hyper-Threading (a processor feature that allows Intel processors to run multiple threads on the same core simultaneously, sharing functional units and caches) is basically the devil. It’s a well-written paper. I learned things from it. Percival is obviously smart. So I’m going to berate it. Here’s why:

The paper builds on previous work (the latter paper is authoritative, the former more fun to read) to point out that cache sharing can allow for side-channel attacks. Percival comes up with two conclusions:

1. Because cache sharing allows one thread to affect the cache of another thread programmatically (creating timing differences that are structured and can be analyzed), the cache timing effect creates a covert channel. Well, duh. Isn’t any side-channel leak a covert channels? The covert channel “insight” drives the bulk of this paper. Ok, it’s a clever (or at least, complicated) way to create a covert channel. But Percival apparently wasn’t the first to come up with this idea. And how important is the discovery of a local covert channel? Why do we think we can prevent them at all? The elimination of covert channels across a single machine involves removing all structure from any of the side effects caused by any program on the system. Good luck.

2. Taking that a step further, how important is the discovery of a local timing attack? The second part of Percival’s paper demonstrates how to use the cache timing channel to extract keys from OpenSSL. That’s sexy. But, as my friend Nate points out, it’s not a new threat. Typical fast crypto on an x86 processor is going to be locally timeable whether you disable HTT or not.

I have a couple problems with the way this discussion is moving.

• Percival is marketing himself more than contributing to the discussion. His response to somebody questioning his change to disable HTT on FreeBSD by default? “Are you working for Intel?”. At no point since Bernstein pointed out Tromer’s paper on sci.crypt have I seen Percival acknowledge the previous work.

  Today on Slashdot, Percival attacked Linus for advancing the reasonable argument that the HTT threat didn’t warrant a drastic change to default Linux configurations. “it at times like this that Linux really suffers from having a single dictator in charge…”. That’s skillful messaging, Percival; an invitation to a BSD vs. Linux debate on Slashdot. It’s also a sleazy emotional pitch.

• This paper follows on the heels of a genuinely interesting timing attack result, which is that AES appears to be particularly susceptable to remote (that is, over IP networks) key extraction using the same cache timing channel. But nobody is talking about that result, because Dan Bernstein isn’t a member of the right clique to get articles posted on Slashdot.

  Compared to the idea that you can extract key bytes by observing timing differences over ethernet, the idea that you can do the same trick locally seems less important. Taking that observation a step further:

  • Dan Bernstein (scholar hits: 376) uses his result to advance the idea that we should avoid s-box-reliant algorithms in favor of constant-time algorithms that are more resistant to timing attacks.

  • Colin Percival (scholor hits: 31) uses his result to advance the idea that disabling HTT by default dramatically improves resistance to timing attacks.

  Problem: one of these observations is valid, but hard to act on. The other is probably invalid, but easy to act on. Guess which gets all the attention.

Like I said, I actually like this paper (and I definitely don’t pretend to be an authority on the subject matter). Mostly, it’s the crowd of hanger-ons that are pushing this issue as a clique-defining political cause that bother me.

No Comments