Slashdot Mirror

Paul Kocher, president of Cryptography Research, Inc. and one of the architects of SSL 3.0, said, "The questions were great -- definitely one of the most fun interviews I've ever done." His answers score high on the 'informative' scale, too. Thanks to everyone who submitted such fine questions, and thanks to Paul for putting some real time and effort into his answers.

1) Serious Threats?
by Prizm

While studying cryptanalysis, I've been learning about a number of interesting attacks such as timing attacks and differential power attacks (your specialty, if I recall). While these attacks certainly seem to help cryptanalysis of various ciphers, how practical are they in terms of real security? That is to say, what are the chances that these methods are actively being used by attackers?

Paul:

It depends on the target. If the system you are trying to protect isn't worth an attacker's effort, or if there are easier ways to break in, the chances are small. On the other hand, if you are protecting extremely desirable data (money, data that will affect stock prices, Star Trek episodes, government secrets, etc.) you have to assume that smart people are going to attack your security. We spend a lot of time helping credit card companies and other smart card users build testing programs -- their products need to operate in high-risk environments where DPA, timing analysis, and other sophisticated attacks are a real problem.

2) Worst implementation?
by burgburgburg

In your consulting capacity (and without naming names), have you ever run across a companies security implementation that was so bad, so insecure, so open to exploitation that you felt an overwhelming compulsion to shut down the servers, lock the doors and call in a security SWAT team? That you actually felt like going out and shorting the companies stock? That you had to hold back from whomping someone upside the head? That you inquired about having the head of security investigated to make sure he wasn't a black hat hacker/competitor's security spy/foreign agent? How bad was the worst implementation you've ever seen?

Paul:

To save typing, can I make a list of the systems that don't make me uncomfortable?

A smart, creative, experienced, determined attacker can find flaws in just about any standard commercial product. Our security evaluations find catastrophic problems more than half the time, even though evaluation projects generally have very limited budgets.

The most common situation is where the systems' security objectives could theoretically be met if the designers, implementers, and testers never made any errors. For example, in a quest for slightly better performance, operating systems put lots of complexity into the kernel and give device drivers free reign over the system. This approach would be great if engineers were infallible, but it's a recipe for trouble if all you have are human beings.

What I find most frustrating isn't bad software -- it's situations where we tell a company about a serious problem, but they decide to ignore it because we're under an NDA and therefore the problem won't hurt sales. If your company is knowingly advertising an insecure or untrustworthy product as secure, try to do something about it. Intentionally misleading customers is illegal, immoral, and a gigantic liability risk. (Keywords: Enron, asbestos, cigarettes.)

It's also frustrating that users keep buying products from companies that make misleading or unsupported claims about their security. If users won't pay extra for security, companies are going to keep selling insecure products (and our market will remain relatively small :-).

As for the worst security, I nominate the following password checking code:

  gets(userEntry);
     if (memcmp(userEntry, correctPassword, strlen(userEntry)) != 0)
         return (BAD_PASSWORD);

ROT13 SPOILER: Na rzcgl cnffjbeq jvyy cnff guvf purpx orpnhfr gur pbqr hfrf gur yratgu bs gur hfre ragel, abg gur yratgu bs gur pbeerpg cnffjbeq. Bgure cbgragvny ceboyrzf (ohssre biresybjf, rgp.) ner yrsg nf na rkrepvfr sbe gur ernqre. [Funzryrff cyht: Vs lbh rawbl ceboyrzf yvxr guvf, unir fgebat frphevgl rkcrevrapr, pbzzhavpngr jryy, naq jnag n wbo ng n sha (naq cebsvgnoyr) pbzcnal, ivfvg uggc://jjj.pelcgbtencul.pbz/pbzcnal/pnerref.ugzy.]

3) Internet broken?
by bpfinn

The Internet was primarily designed for use by researchers who were collaborating on similar projects, and so security was not part of the design. Would you advocate designing and building another Internet where security was a major design goal? Or can we tweak the current Internet to reduce that amount of maliciousness that goes on now?

Paul:

I don't think the core Internet is the problem. While some protocols need upgrading, the Internet does a great job of providing untrusted, unreliable communications. Trying to impose security policies in the network layer would destroy the spontaneity and openness that make the Internet great. In other words, we need to find ways to cope with the fact that the Internet is always going to be dangerous.

The place where I see the real need for improved security is in the protocols, applications, and devices that use the Internet. For example, Moore's Law has made processing power so cheap that there is no reason why web pages aren't all encrypted. Similarly, IPSEC, VPN tunnels, and e-mail encryption should be used much more widely.

Of course, large networks are always going to have unpredictable complex security risks. As a result, if you are dealing with critical systems, they should be as disconnected as possible.

4) Dive Right In
by Accidental Hack

What does a newbie do? Having been put in a position where I'm partly responsible for server security, and having been put in that position without the proper background (and the responsibility is here to stay), how do I get my head straight on the core issues and make sure I'm not leaving the doors open for anyone to do whatever they want? Reading books/articles doesn't seem to be enough, but if that's the best place to begin, any recommendations?

Paul:

You are really asking two questions: how to learn about security, and what to do if you are put in situations where you don't know what to do.

For people wanting to learn about security or cryptography, I'm a big supporter of hands-on experience. When you hear about a security bug, go see what actually went wrong. Implement DES, AES, RSA, and your own big-number library. Set up a couple of poorly-configured Linux boxes and break into them. Install a sniffer and sniff your own network traffic. Observe and modify software programs. Learn C/C++. Study known bugs in open-source crypto code and hunt for new ones. If you have the budget at work, hire a security expert and ask lots of questions. Whatever you do, be careful to follow the laws (even if you disagree with them) and act ethically.

The question of what to do if you are put in a situation beyond your skill level ultimately depends on the risks involved. With ordinary servers (corporate e-mail and the like), occasional problems may not be that catastrophic if you have good backups.

On the other hand, if the chances or consequences of failure are severe, you can't just "give it a try" any more than I should try open heart surgery or piloting a 747. For example, if you are dealing with critical infrastructure, likely fraud targets, pay TV networks (or anything involving piracy), or large customer databases, get help. Even if you are experienced, you need to have someone check your work. When you do hire someone, make sure they will answer questions, educate you, and provide good documentation. Avoid mad scientists, people who have never done serious engineering, and anyone who views security audits as threatening or insulting.

5) Quantum Computing and Cryptography
by Nova Express

Will the advent of quantum computing render even current, state-of-the-art cryptography obsolete? Is there any way that cryptography can overcome the challenge presented by quantum computing? And how long will it be, if ever, until quantum computer's can break current, state-of-the-art cryptography?

Paul:

Quantum computing is possibly the coolest discovery in theoretical computer science in the last few decades because it completely changes the rules of computation.

As a practical matter, however, it's not a significant security risk compared to the other things we have to worry about. I think it's highly unlikely that quantum computers will overtake regular computers in the next 50 years at (for example) breaking RSA. The reason for my skepticism is that the challenges involved in building a useful quantum computer are staggering. For example, decoherence becomes a much greater problem as the computer gets larger, yet quantum computers have to be huge because they don't operate sequentially. (Imagine hardware design with no flip flops -- just combinatorial logic.) While error-correction techniques have been proposed, these further increase the complexity of the circuit.

If someone did find a way to build arbitrarily large quantum computers, it would be the end of most existing public key cryptographic schemes. Symmetric cryptography, however, would still work, though key lengths would need to be doubled to get the same level of security.

Note: Quantum computing is different from quantum cryptography. The latter is a method for preventing eavesdropping, typically using polarized photons and entanglement. While quantum cryptography is feasible to implement and is also neat research, I don't see any practical use for it because it requires that parties exchange photons directly. As a result, it won't work over packet switched networks. Furthermore, existing algorithms like AES can do all the same things, and much more. As a result, the only scenario I can see where quantum cryptography would be relevant would be unbelievably weird discovery that completely demolished cryptography, such as someone showing that P=NP.

6) SSL and Forward Security
by Effugas

Paul,

First of all, thank you for agreeing to be interviewed here. It's greatly appreciated.

I'm curious if you wouldn't mind elaborating a bit on the catastrophic failure of the SSL security architecture given the compromise of an RSA private key. An attacker can literally sniff all traffic for a year, break in once to steal the key, then continue to passively decrypt not only all of last year's traffic but all of next year's too. And if he'd like to partake in more active attacks -- session hijacking, malicious data insertion, etc. -- that's fine too.

In short, why? After so much work was done to come up with a secure per-session master secret, what caused the asymmetric component to be left so vulnerable? Yes, PGP's just as vulnerable to this failure mode, but PGP doesn't have the advantage of a live socket to the other host.

More importantly, what can be done for those nervous about this shortcoming in an otherwise laudable architecture? I looked at the DSA modes, but nothing seems to accelerate them (which kills its viability for the sites who would need it most). Ephemeral RSA seemed interesting, but according to Rescola's documentation it only supports a maximum of 512 bits for the per-session asymmetric key -- insufficient. If Verisign would sign a newly generated key each day, that'd work -- but then, you'd probably need to sign over part of your company to afford the service. Would it even be possible for them to sign one long term key, tied to a single fully qualified domain name, that could then sign any number of ephemeral or near-ephemeral short term keys within the timeframe allotted in the long term cert?

Thanks again for any insight on the matter you may be able to provide!

Yours Truly,

Dan Kaminsky
DoxPara Research

Paul:

I specifically designed the ephemeral Diffie-Hellman with DSA option in SSL 3.0 to provide perfect forward secrecy (PFS). While it used to be true that DSA's performance was a concern, it shouldn't be a problem anymore.

[*] If you want to avoid DSA, you can also do a normal RSA handshake then immediately renegotiate with an uncertified ephemeral Diffie-Hellman handshake. (SSL 3.0 and TLS 1.0 allow either party to request a renegotiation at any time, with the renegotiation process protected underneath the first handshake.) As your question mentions, short-lived certificates would work if a suitable CA provided them.

Making PFS mandatory wasn't feasible in SSL 3.0 because of performance requirements, the need to maintain compatibility with legacy RSA certificates, and licensing issues. (Back in 1996, RSA was patented and most companies only had limited RSA toolkit licenses, not patent licenses.)

Overall, I'm delighted so see how many ways SSL 3.0 is being used and that it's become the most widely deployed cryptographic protocol in the world. While there are reasons to debate design choices I made, I don't know that the protocol's handling of PFS is one of them. Although some implementations have had bugs and guidelines had to be added to address error-analysis attacks, the overall protocol has held up well.

[*] In 1996 (when the SSL 3.0 spec came out), computers were only 4% of their current speed. (Moore's Law predicts 4.67 speed doublings in 7 years.) Today, any modern CPU should give well beyond 200 2048-bit DSA verifies/second. Averaging 10 handshakes/second (5% load) = 864K connections daily per CPU. Unless you are running one of the largest web sites (or have your server misconfigured to disable session resumption), this isn't likely to be a problem. For really high-volume servers, SSL accelerators are affordable and very fast. In general, it's rare these days to find a situation where the speed of standard cryptographic operations is actually a problem.

7) trust in open p2p communities
by smd4985

as a software engineer building open source p2p applications (gnutella), we are faced with a huge problem: how do we establish trust in a open environment where any application that speaks the protocol can participate? we've thought of various cryptographic systems to establish trust, but they have several fatal flaws - they require some sort of centralization (a no-no in a p2p environment), they lock out 'untrusted' vendors, etc.

what can we do to maintain an open environment and establish trust between peers?

Paul:

There certainly are decentralized ways to establish trust (PGP's web of trust comes to mind), but you can't have trust and complete anonymity. The closest you'll be able to do is to evaluate participants based on their past actions and assertions. Before you can begin a design, you'll need to clearly define what you are trying to enable, what you are trying to prevent, and what automated rules can distinguish between legitimate and illegitimate actions.

(Note: While I presume that the question relates to legitimate P2P applications, piracy over P2P systems is driving copyright owners to seek legislative and legal relief. The fact that the Internet can be used to massively violate intellectual property rights doesn't make it moral to do so.)

8) How do you think?
by Charles Dodgeson

When I first read about some discovery of a weakness (for example, I know your name from your work on MD5), I am always struck by the thinking beyond the framework of the designer of the system and of the community to date. The same things strikes me about timing attacks and similar sorts of things. These are things that I wouldn't have thought of in a million years. Can you give any insight into how minds like yours work. And to what extent you think that this might be a trainable skill.

I normally hate the cliche of "thinking outside of the box", but here it is fully appropriate.

Paul:

Security work requires understanding systems at multiple levels. For example, differential power analysis involves transistor-level properties affecting logic units affecting microcode affecting CPUs affecting crypto algorithms affecting protocols affecting business requirements. For engineers who are used to working at only a single layer, security results often seem surprising. Broad experience is also important because the vast majority of security problems involve unintended interactions between areas designed by different people.

Two specific subjects that I think are often neglected are low-level programming and statistics. These are essential to understand how things actually work and to assess the likelihood that systems will fail. A skeptical mindset is also important. Try to assume things are bad until you are convinced otherwise.

Some specific questions that are helpful to ask include:

• What information and capabilities are available to attackers?
• What information and capabilities are available to attackers?
• What esoteric corner cases has nobody studied carefully?
• How would a lazy or inexperienced designer have designed the system?
• What states can each participant be in?
• Where is the most complexity in the security perimeter? (Complex parts are the most likely to fail.)
• What unwritten assumptions are being made, and are they correct?

If you aren't sure how to begin an evaluation, consider sketching out how you would have done the design. You can then compare your design against the target. The differences often reveal mistakes you made (a great way to learn) or identify problems with the target system.

9) Is the Technology ahead of us?
by Coz

Thanks for letting us ask you these questions.

Over the last couple of decades, cryptography has gone from being the domain of major governments, big business, and the odd hobbyist and researcher to being a massive public industry that anyone can (and does) participate in, with new algorithms published and new applications announced almost every week. Meanwhile, we learn of vulnerabilities in various implementations of cryptosystems much more frequently than we hear of people discovering fundamental flaws in the cryptosystems themselves.

Given these facts, do you think we need to change focus, turning to validating and "approving" implementations of cryptosystems (such as your own SSL 3.0) or should the emphasis of the "crypto community" continue to be innovation in fundamentals of cryptographic systems and new applications for them? How important is it to have someone verify that a cryptosystem is implemented well?

Paul:

Validation is by far the most critical unsolved problem in security.

I view security as probabilistic: there is always some chance of failure, and validation is the only way to reduce the odds of failure. For example, a well-tested piece of code is more secure than an identical piece of code that hasn't been tested.

Although innovation is great on the research side, real-world systems should use well-tested techniques wherever possible. For example, on the algorithm side, we use RSA, triple DES, AES, and SHA-1 at Cryptography Research unless we have to use something else. (This is rare.) We use these algorithms because they are well reviewed, making the risk of an unexpected cryptanalytic attack low. In contrast, catastrophic flaws in new schemes are very common.

When you move beyond the basic algorithms, validation unfortunately becomes extremely difficult for many reasons:

• The complexity of software is increasing exponentially, but the number of skilled security experts (and their intelligence and productivity) is staying roughly constant.
• Many designs are so poorly architected or implemented that they are infeasible to validate.
• Validation is much more difficult than writing new code (and it's less fun), so many people avoid it.
• Engineers are cranking out such vast quantities of code that testing can't possibly keep up.
• Existing validation tools are really quite poor.
• The cost of security testing can be hard to justify because most users won't pay extra for better security.
• There is no easy way for users to distinguish between well-tested products and those that aren't.
• Testing takes a long time, slowing down product launches.
• There is no easy way to standardize security evaluations because attackers don't limit themselves to standard attacks.
• Catching 90% of the flaws doesn't help if attackers are willing to look 10 times harder to find flaws.
• Developers don't have much incentive to make painful sacrifices for security because they aren't the ones who incur the risk.

Long-term, I expect security will become like the pharmaceutical and aviation industries. Regulations and liability would improve safety, but would also make product development hugely expensive. Regardless of whether this would be better or worse than the current state of affairs, it looks inevitable.

10) Re:fhnlsfdlkm&5nlkd%Bvbcvbc
by Anonymous Coward

0eefa Uv, V'z jbaqrevat vs lbh guvax gurer'f n shgher sbe EBG13. V'ir urneq vg'f cerggl frpher...

Lbh pna ernq guvf? Qnza!

Paul:

Holy cow! Juvyr lbh znl unir svtherq bhg zl fhcre-frperg EBG13 pvcure, abobql jvyy rire penpx *guvf* zrffntr orpnhfr V fjvgpurq gb bhe hygen-frperg cyna O: nccylvat n Pnrfre pvcure 13 gvzrf :-).

rf0 writes "Well CERT is reporting a new overflow attack for IIS 5.0. Microsoft has released a bulletin. Better download those patches and fix another security hole." According to this CNET story, Microsoft says that this is already being exploited, at the very least since last Wednesday.

rf0 writes "Well CERT is reporting a new overflow attack for IIS 5.0. Microsoft has released a bulletin. Better download those patches and fix another security hole." According to this CNET story, Microsoft says that this is already being exploited, at the very least since last Wednesday.

campusNetworkWatcher asks: "I work for a large University that allows wide open access to most of its networks. There is no firewall of any type, and this is not likely to change in the future. A problem spot I see are the residential networks. For the most part, it is filled with un-patched Windows machines run by non-security-centric users just waiting for the newest virus/worm/trojan. Recent events, and an onslaught of DMCA violations have caught the attention of my superiors (as well as his superiors), but there is little we can do once we track down a compromised machine. With a couple of exceptions, in a couple of departments, there is no group will to do desktop support of student machines. We can tell a user he or she is compromised, but lack the enforcement to make the user fix the problem. My group strongly advocates an open academic environment, but if the network is too open it may negatively affect the people we are running it for. I feel like this must be a problem for many other universities and was wondering how others have handled it (blanket port blocking of NetBIOS, established only traffic, or other options). I am looking for non-intrusive suggestions for protecting the network, while allowing as much access as possible to the students. Any suggestions?"

Rich0 writes "Sun is announcing that their 'Security Hardening Package' for their Cobalt RaQ 4 Linux servers allows remote users to execute arbitrary code. Ironically, the solution is to remove the package, potentially removing protection from other compromises. There's a CERT advisory, as well as an article posted on Extremetech." Yikes, one would hope there's a forthcoming patch in the works.

eecue writes "The world's most popular DNS package is once again vulnerable. Even the advisory says it's only a matter of time before worms are written.... just like a couple years ago. I guess this is why i run tinydns."

Phil writes "The MSS Initiative was started by Richard van den Berg and myself to combat sites that are broken (enable Path MTU Discovery AND block ICMP 3,4) which include such big sites as SecurityFocus and CERT (causing those behind PPPoE and other less-than-1500-MTU-protocols to be unable to view the sites). This past week we were priveleged enough to be able to present a paper at the 16th LISA Systems Administration Conference! Check out the paper and slides and be sure, like many members of the audience, to fix the sites you administer!"

Scoria writes "According to a CERT advisory published this afternoon, the public distribution of Sendmail 8.12.6 contained a trojan horse from September 28 to October 6. For more detailed information, please consult advisory CA-2002-28." This sounds very much like what happened to OpenSSH.

A reader writes:"On NewsForge, there is an interview with a system administrator looking for an officially supported FrontPage install for RedHat Linux Apache rpm to fix CERT Advisory CA-2002-17 , which has already found in the wild. According to the interview Microsoft may, at some point, release an official patch or upgrade which Apache, RedHat and others fixed long ago."

NeedaFirewall writes: "With all of the recent vulnerability announcements and increased concern about terrorism, a lot of folks are starting to take security and privacy more seriously, both at the network and node levels. Large companies can afford to send their IT people to detailed technical security conferences offered by the likes of SANS, Blackhat, and others. Some of these cost thousands of dollars for a single seminar, class, or other event. Small companies and individual programmers, network admins, etc (like me!) often can't afford these. Where can they go to learn more about security? Are there quality security conferences, seminars, trade shows, and the like out there that the little guys can afford? Particularly broad-scope gatherings that can teach these 'security newbies' the basics and alert them to the most pertinent threats?"

codewolf writes "It has been reported to bugtraq by Domas Mituzas that a worm that exploits the Apache chunk bug has been found in the wild. Information on the worm can be found here. More information on the Apache bug can be found here, and patches can either be made by modifying your config file or upgrading your Apache version."

cliffwoolley writes "The Apache Software Foundation has released new versions of both Apache 1.3 and 2.0. These versions are both security and bug-fix releases. They address and fix the issues noted in CAN-2002-0392 [CERT VU#944335] regarding a vulnerability in the handling of chunked transfer encoding. You can download the new releases here." This of course is for the exploit that we reported yesterday. It is hard to complain about a 24-hour response time for a bug.

wiredog writes: "From ZDNET comes the news that there is apparently a serious security flaw in the Simple Network Management Protocol, used to control routers and other network devices." An anonymous reader points to the CERT advisory as well.

An anonymous submitter sent in: "A CERT Advisory describes a buffer overflow vulnerability in implementations of login derived from System V, which includes among Solaris 8 and earlier and AIX 4.3/5.1. "An exploit exists and may be circulating." Vendors are testing fixes." There's a Reuters story as well.

Slashback tonight with updates on SSH vulnerabilities, the Queen's web server, the European answer to GPS (in danger, it seems) and your ever-thinner rights to use software for anything you don't have specific permission for.

Sometimes being British means self-flagellation. Ferox writes: "The November Web Site Survey from Netcraft reveals something interesting: 'Two years ago the Queen of England became an unlikely icon for the Linux revolution when her webmaster replaced Solaris as the platform for the Royal Family's site, citing the better price/performance of the Dell/Linux platform over the previous incumbent, Sun/Solaris. The open source community celebrated and speculated on when the Apache web server might receive the "By Royal Appointment" moniker. This week the site has changed platforms again, this time to Microsoft-IIS.'"

Keep your hands and passwords inside the car at all times. Niels Provos passed along word of his ongoing research into network security, with some slightly depressing news about the state of Internet security.

Even though the CRC32 bug has been found over a year ago, over 30% of all servers are still vulnerable today. Graph at http://www.citi.umich.edu/u/provos/ssh/crc32.png.

In February 2001, Razor Bindview released their "Remote vulnerability in SSH daemon crc32 compensation attack detector" advisory, which outlined a gaping hole in deployed SSH servers that can lead to a remote attacker gaining privileged access.

In November 2001, Dave Dittrich published a detailed analysis of the "CRC32 compensation attack detector exploit." This exploit is currently widely in use. CERT released Incident Note IN-2001-12.

At the Center for Information Technology Integration, Niels Provos and Peter Honeyman have been scanning the University of Michigan for vulnerable SSH server software to identify and update vulnerable SSH servers. However, scans of the Internet show that system and security administrators must react and update their SSH servers. At this writing, over 30% of all SSH servers appear to have the CRC32 bug.

A simple solution is to remove support for Version One of the SSH protocol. The majority of servers on the Internet support the SSH v2 protocol. To test whether your network has vulnerable SSH servers, you might use the ScanSSH tool.

References: "ScanSSH - Scanning the Internet for SSH Servers", Niels Provos and Peter Honeyman, 16th USENIX Systems Administration Conference (LISA). San Diego, CA, December 2001. This information is also available at http://www.citi.umich.edu/u/provos/ssh/

Don't play with your food, or your games. janolder writes "In the matter of the Civilization III translation project (articles on slashdot, apolyton and heise), the fans have gotten the short end of the stick. The project web site (translation.civ3.de) has been down for a while. Earlier this week, both the web site operator and Kai Fiebach, the project leader, signed Infogrames' cease and desists out of fear of further legal action. The legal position (not to mention the moral postion) of the fans did not appear to be too weak - EULA's are not binding in Germany and supplying patches to a program is certainly not the same as translating a book and distributing the translated manuscript.

Infogrames Germany has issued another press release (translation and my comments) justifying their legal action and position. It makes for an interesting peek into the mindset of a game publisher.

The good news is that Infogrames is considering a more timely release of Civilzation III in Germany.

The bad news is that the cease and desists apparently forbid any modification of Civ3 in any way, shape or form. So no more custom maps for your friends, custom rules or any such copyright infringing activity, please! Is it just me, or has the world suddenly become a less interesting place?"

Not as if Americans always know where we are, either. ByTor-2112 writes "Hate to be the bearer of bad news so soon after a story is posted, but as I commented on the previous story, it appears that galileo has some funding issues. Honestly, did anyone really expect the EU to go through with it? It took them long enough to agree on a common currency!"

alteran writes "CERT has released a paper (PDF) analyzing changes in DOS attack methods. The new twist-- crackers are increasing getting into routers rather then servers and home PCs. The volume of noise a router could generate absolutely dwarfs what a computer could do. And unlike compromised servers, compromised routers could actually screw up the infrastructure of the Internet, not just blast people with packets. Worst of all, router administators appear to be even sloppier than their server counterparts in securing their machines."

alteran writes "CERT has released a paper (PDF) analyzing changes in DOS attack methods. The new twist-- crackers are increasing getting into routers rather then servers and home PCs. The volume of noise a router could generate absolutely dwarfs what a computer could do. And unlike compromised servers, compromised routers could actually screw up the infrastructure of the Internet, not just blast people with packets. Worst of all, router administators appear to be even sloppier than their server counterparts in securing their machines."

We had thought we were done with Code Red last week, but CERT is sending out warnings that the entire internet will cease to exist if the Code Red MSTD ^[?] isn't stopped in its tracks. Even Scientific American has a story about it. Cringely tells us that the true threat is servers with mis-set clocks.

The first direct legal challenge to the DMCA was filed at 9 a.m. EDT today by EFF-sponsored attorneys at the United States District Court in Trenton, New Jersey on behalf of Princeton Professor Edward W. Felten and others who helped crack a series of digital watermarking schemes as part of an SDMI Challenge sponsored by the RIAA. Named defendents include the RIAA, SDMI, Verance Corporation (producer of one of the cracked watermarked schemes) and U.S. Attorney General John Ashcroft.

If this were a movie, it might be called "Saving Professor Felten" and would open with thunder and bombast. In real life, filing a civil suit in a federal court is one of the most boring activities imaginable, even though it's a necessary first step in the process of overturning the DMCA.

Gino J. Scarselli, Outside Lead Counsel for EFF on the case, says, "We got to the courthouse at 8:30, filed around 9, and made motions to seal exhibits to the complaints." As explained in the Complaint itself, EFF filed several of their Exhibits with requests for them to be sealed, because they believe publication of them may invite a lawsuit. The Exhibits to be sealed are Professor Felten's completed paper for the upcoming USENIX conference, and two documents written by Princeton post-grad Min Wu about the investigation performed by Felten's team against the SDMI watermarks.

It was an overcast day in Trenton. Scarselli, along with local (New Jersey) attorneys Grayson Barber and Frank Corrado, and two of the plaintiffs, Princeton residents Bede Liu and Min Wu, went through a metal detector just like anyone else (aside from staff) who enters a courthouse these days.

Scarselli says, "the only person we talked to was a law clerk." Neither the defendants nor any lawyers representing them were present. There will be plenty of conflict later, but the opening round of this drama was so low-key that it was a total yawner for all involved parties. The whole thing was over by 9:45 a.m.

The Complaint Itself, Very Briefly

Prof. Felten and others, mostly professors and graduate students from Princeton and Rice Universities, accepted the SDMI challenge to crack a specific set of digital watermarks, but instead of turning their results over to SDMI in hopes of winning the $10,000 prize offered for a successful crack, they chose instead to publish their findings in the form of an academic paper, and to present that paper at the Fourth International Information Hiding Workshop [IHW], held in Pittsburgh on April 25-27, 2001. Felten and crew believed they had every right to present their research in this public, peer-reviewed scientific forum even though they had accepted a "click through" agreement before taking on the SDMI challenge, in large part because the license to which they agreed with their click contained these words:

"You may, of course, elect not to receive compensation, in which event you will not be required to sign a separate document or assign any of your intellectual property rights, although you are still encouraged to submit details of your attack."

Despite this, SDMI threatened Felten and the other involved parties, including IHW organizers, with legal action under the DMCA. After a long series of emails between Felten, his fellow researchers, IHW people, a representative of Verance Corp., and an attorney who works for both SDMI and RIAA, the original paper, "Reading Between the Lines: Lessons from the SDMI Challenge," was first modified, then finally withdrawn.

Now Felten and friends plan to present the same paper at a USENIX Security Symposium in Washington, D.C. on August 13-17, and are asking the court to tell the defendants not to sue or threaten legal action over this new publication or any other publication, and to tell the U.S. Department of Justice, run by Attorney General John Ashcroft, not to file criminal charges against USENIX or anyone else over this matter under the DMCA. As it says in the complaint:

68. In chilling publication, the DMCA wreaks havoc in the marketplace of ideas, not only the right to speak, but the right to receive information -- the right to learn. The main mission of USENIX is to organize forums where scientists and researchers learn from each other. By intimidating the individual plaintiffs into withdrawing their paper from the IHW, however, the private Defendants prevented people from learning. If the source of Defendants' power to threaten, the DMCA, is not dispelled, Plaintiffs will not be the only victims. Without full and open access to research in areas potentially covered by the DMCA, scientists and programmers working in those areas cannot exchange ideas and fully develop their own research. As a consequence, the DMCA will harm science.

69. By imposing civil and criminal liability for publishing speech (including computer code) about technologies of access and copy control measures and copyright management information systems, the challenged DMCA provisions impermissibly restrict freedom of speech and of the press, academic freedom and other rights secured by the First Amendment to the United States Constitution.

This is just a brief "taste" of what the complaint says. Full text is available here.

The Press Conference

It was held at noon Eastern time, in person simultaneously at EFF headquarters in San Francisco and at a room borrowed from Princeton University. A few reporters were at EFF headquarters in person, but most of us dialed in and participated by phone. The media turnout was impressive; reporters from the Boston Globe, Wall Street Journal, New York Times, AP, NPR, Reuters, Wired, and other major news outlets showed up, which was nice to see; Slashdot has been rather lonely in covering many DMCA matters and complaints. It was nice to see so many "mainstream" pressies finally paying attention.

Felten was in San Francisco. So was most of the legal crowd. USENIX Board member Avi Rubin was on the conference call telephone. The Princeton contingent was tiny, composed only of the people who had been at the court house earlier. EFF legal director Cindy Cohn opened the show from San Francisco with a rehash of the events leading up to the suit, most of which I recapped above. (You can find more information here.)

Felten spoke briefly. The basic thrust of his prepared speech can be summed up thusly: "We are asking the government to let us do what scientists have always done -- share the results of our research."

The USENIX people noted that they hold many conferences and may be subject to both civil suits and criminal prosecution if they publish papers DMCA legal threateners (like SDMI and RIAA) don't like, and view this suit as an attempt to maintain their First Amendment rights to freely distribute technical and scientific information to USENIX members and other interested parties.

Then the press questions began. The first dozen covered ground that is familiar to most regular Slashdot readers. There is no point in rehashing these questions when a Slashdot search for "SDMI + DMCA" or just "DMCA" will give answers to every one of them.

Then Hiawatha Bray, a tech columnist for the Boston Globe, wanted to know if the case would be dropped if the SDMI and/or RIAA decide to stop hassling Felten and USENIX. The attorneys said "No." Their point here is to prevent both private companies and the DoJ from bringing DMCA threats not only against the SDMI crack researchers but against anyone who might go through the same sort of ordeal in the future, so a settlement that affected only this case would not cause the EFF to drop it. Other questions and answers followed, but again, long-time Slashdot readers already know most of them, so we won't repeat them here.

Follow the Money

Ms. Cohn says the cost of this suit, "if fully litigated," could easily reach $2 million. She estimates that the EFF-sponsored 2600 DeCSS defense has already cost nearly $1.5 million, and that suit is still cranking up the appeals chain. She also says -- yes, this is a plug -- that Slashdot readers who want to donate money to help fund all this expensive legal action can check out the EFF Web site.

(Here's the EFF membership/donation page if you'd like to whip out your credit card and pop a few bucks their way; they need all they can get!)

This is Just the Beginning

Now, basically, we sit and wait. The lawyers do lawyer-dances involving lots of paperwork. Discovery motions pass back and forth. Amicus briefs get filed. A hearing date gets set, then there's a hearing, and another hearing, and so on.

The 2600/DeCSS case has been going on for a year and a half and still isn't over. This one is likely to drag out even more. Even if Prof. Felten, his associates, and USENIX win all the relief they seek, chances are high that the RIAA, SDMI or at least one of the other defendants will appeal -- and keep appealing all the way to the U.S. Supreme Court.

For more info, read the EFF Press Release

If you are interested in reading an informative article on attacks against TCP connection sequences, CERT has posted a nice alert about it. The article does a nice job of going into the history of such attacks. Normally I find CERT's pretty worthless and outdated compared to what you find on Bugtraq, but this one is pretty good.

If you are interested in reading an informative article on attacks against TCP connection sequences, CERT has posted a nice alert about it. The article does a nice job of going into the history of such attacks. Normally I find CERT's pretty worthless and outdated compared to what you find on Bugtraq, but this one is pretty good.

John Langford sent in the statement read by Dr. Edward Felten, a professor at Princeton University, who decided to skip presenting the paper he co-authored at a scientific conference due to legal threats made by the RIAA. The RIAA put out an open challenge in September 2000, requesting that researchers attack and crack the SDMI watermarking scheme, but demanded that anyone who researched the scheme suppress their results in order to be eligible for a cash prize. "Show off your skills", they said, but they didn't mean it. Felten and colleagues declined the cash prize and its accompanying restrictions, but have been threatened anyway - the RIAA would have brought a lawsuit claiming the research paper is a circumvention device forbidden by the DMCA, much like the DeCSS case.

Statement read by Edward W. Felten
Fourth International Information Hiding Workshop
Pittsburgh, PA
April 26, 2001

"On behalf of the authors of the paper "Reading Between the Lines: Lessons from the SDMI Challenge," I am disappointed to tell you that we will not be presenting our paper today.

Our paper was submitted via the normal academic peer-review process. The reviewers, who were chosen for their scientific reputations and credentials, enthusiastically recommended the paper for publication, due to their judgment of the paper's scientific merit.

Nevertheless, the Recording Industry Association of America, the SDMI Foundation, and the Verance Corporation threatened to bring a lawsuit if we proceeded with our presentation or the publication of our paper. Threats were made against the authors, against the conference organizers, and against their respective employers.

Litigation is costly, time-consuming, and uncertain, regardless of the merits of the other side's case. Ultimately we, the authors, reached a collective decision not to expose ourselves, our employers, and the conference organizers to litigation at this time.

We remain committed to free speech and to the value of scientific debate to our country and the world. We believe that people benefit from learning the truth about the products they are asked to buy. We will continue to fight for these values, and for the right to publish our paper.

We look forward to the day when we can present the results of our research to you, our colleagues, through the normal scientific publication process, so that you can judge our work for yourselves."

The Dev was the first of several zillion to point out that security holes were found in BIND. The detailed table of known vulnerabilities will help clarify (and it has tarball links too), but the short version is, if you're running BIND 4 or BIND 8, set aside some time today to upgrade to 4.9.8 or 8.2.3 (not beta, betas of 8.2.3 are vulnerable). And now's a good time to reconsider version 9, too. SecurityFocus warns that the last time a BIND hole of this magnitude was found, it was followed by a "cyber-crime wave." Exploits for these holes were successfully created by COVERT Labs, but nobody seems to know whether they're in the wild yet. Obviously, they soon will be. Post your questions and answers about upgrading below.

Diesel Dave writes "CERT Advisory CA-2001-01 announced today that the Interbase server database contains a compiled-in back door account. The thing is, it was not the result of a malicious code infection, but a direct addition by the original Borland/Inprise authors done before the program was released as open source." The backdoor was installed sometime between 1992 and 1994, and has been included in every version of Interbase during that time.

Carnage4Life writes "In a radical departure from it's previous stance of security through obscurity, the Computer Emergency Response Team, CERT, has stated that it will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix. The change of policy can be found at the CERT site and there is also a story on C|net. The change is not a complete embrace of full disclosure because CERT will not release exploits as some other software security watchdogs do."

Carnage4Life writes "In a radical departure from it's previous stance of security through obscurity, the Computer Emergency Response Team, CERT, has stated that it will fully disclose all vulnerabilities in software that come to it's notice 45 days after the fact whether or not companies have provided a fix. The change of policy can be found at the CERT site and there is also a story on C|net. The change is not a complete embrace of full disclosure because CERT will not release exploits as some other software security watchdogs do."

Tairan writes: "Crackers are using two exploits to ready another distributed Denial of Service attack. MSNBC.com is reporting there are at least 560 computers infected. CERT claims it 'poses a significant threat to Internet sites and the Internet infrastructure.'"

Tairan writes: "Crackers are using two exploits to ready another distributed Denial of Service attack. MSNBC.com is reporting there are at least 560 computers infected. CERT claims it 'poses a significant threat to Internet sites and the Internet infrastructure.'"

The Apache Software Foundation has just announced the release of Apache 1.3.12, the latest version of the Apache Web server. The main improvements in this release are designed to handle the "cross site scripting" issues reported in http://www.cert. org/advisories/CA-2000-02.html and http://www.a pache.org/info/css-security/index.html. The full announcement goes into more detail.

Anonymous Coward writes "Cert has published a major advisory on malicious HTML tags embedded in client Web requests. Basically, all clients and all Web servers are affected by this problem. If a Web site does not scrupulously check all input data before posting it back to the user, malicious scripts could be executed over supposedly secure and trusted connections. Recommended solutions include completely overhauling Web sites, disabling cookies and scripts, and 'Web Users Should Not Engage in Promiscuous Browsing.' Sun, Microsoft, and Apache should have notices up on their sites shortly. "

Read the CERT Advisory carefully, because it's a bit complex. A buffer overrun in the RSAREF2 library, a common implementation of a common crypto algorithm, combines with a buffer overrun in version 1 of sshd to allow unauthorized execution of arbitrary code. PGP is not affected. SSH2 is not affected. All versions of the free SSH1 are affected, but only "when --with-rsaref is explicitly supplied on the command line." (On my system, "ssh&nbsp-V" tells me whether I compiled in RSAREF, presumably the same for both client and server.)

Read the CERT Advisory carefully, because it's a bit complex. A buffer overrun in the RSAREF2 library, a common implementation of a common crypto algorithm, combines with a buffer overrun in version 1 of sshd to allow unauthorized execution of arbitrary code. PGP is not affected. SSH2 is not affected. All versions of the free SSH1 are affected, but only "when --with-rsaref is explicitly supplied on the command line." (On my system, "ssh&nbsp-V" tells me whether I compiled in RSAREF, presumably the same for both client and server.)

P.J. Hinton wrote in to send us a link to a CERT advisory explaining that the sources to TCP wrappers were actually replaced with a nice new and improved version. Complete with a trojan. It was caught fairly quickly after it was uploaded, but it's still kinda scary. Update: 01/22 01:07 by CT : Several people sent the Bugtraq post over at Linux Today. A lot more details clarifying the situation.

Old Fart! writes "A new denial of service attack has been discovered- it affects some systems with BSD-derived TCP/IP stacks... "