December 28, 2024

Serious Linux Worm

New.com reports on a new worm infecting Linux/Apache servers. (A “worm” is a malicious standalone program that propagates on its own, without requiring any human action.)

A new worm that attacks Linux Web servers has compromised more than 3,500 machines, creating a rogue peer-to-peer network that has been used to attack other computers with a flood of data, security experts said Saturday.

It was only a matter of time before this happened. Linux in particular, and open-source software in general, are not immune to malware such as worms and viruses. Linux has gotten a free pass for a while, because malware developers, like all software developers, tend to target their code for the most popular platforms. Now that Linux is so popular on servers, it becomes a more natural target for malware.

Of course, whoever did this is a criminal and deserves to be punished.

If there is a silver lining here, it is that this serves as a wake-up call for those who view the poor state of computer security as a “Microsoft problem” or a “closed-source problem.” All software is riddled with bugs, and all security-critical software is riddled with security-critical bugs. We just don’t know how to build large, complex programs without them. Rather than pointing the finger at others, who might or might not have a few more bugs than we do, we all need to figure out how to do radically better than any of us are doing today.

Network Centric DRM

Remember when I promised not to post anymore on Lessig’s DRM piece? I lied. I just have to respond to a comment from Lessig himself.

He writes:

… Felten is skeptical that copyprotection would be placed in the network. “From an engineer standpoint, that assumption looks wrong to me,” he says. But what if we looked at Fritz “not an engineer” Holling’s perspective? The point of my article is that Congress is pushing copyprotection in the network, whatever engineers would argue is ideal….

Let me go farther, then. I don’t think anybody, including Sen. Hollings, is proposing building copy protection into the network itself. The Hollings CBDTPA would regulate “digital media devices,” i.e. endpoints. The proposed BPDG “broadcast flag” rules would also restrict endpoint products. The so-called “consensus watermark” proposals operate at the endpopints too. Normally when people talk about “regulating the Internet,” they’re really talking about regulating the endpoints.

Having said that, let’s not lose sight of the fact that I agree with Lessig about the main points in his article: that kneejerk anti-Microsoftism blinds some people to the real significance of Palladium, and that what Lessig calls “token based” DRM is a lesser evil than what he calls “copy protection”.

Etzioni: Reply to Spammers

Oren Etzioni has an op-ed in today’s New York Times about spam. His proposal:

Though spammers hope to lure us with their dubious propositions (“URGENT AND CONFIDENTIAL BUSINESS PROPOSAL”), they rely on those of us who don’t want to participate to delete their messages quietly and go about our daily business. What would happen if recipients instead replied en masse to each message?

… Faced with hundreds of thousands of responses, the spammer would have to use substantial resources to store the responses, sift through them and identify those registering genuine interest.

This is a well-known Bad Idea. The return addresses on spam emails are often forged, so the “hundred of thousands” of replies might well end up in an innocent bystander’s inbox. If replying to spam became common practice, then forged spam would provide an easy denial of service attack against anybody’s email service, by sending a spam message claiming to come from them.

Like it or not, email messages are easy to forge, so any method of retaliation against the purported sender of spam is bound to backfire.

It’s disappointing to see a suggestion this lame in the Paper of Record, even on the op-ed page.

"Network-Based" Copy Protection

One more comment on Lessig’s Red Herring piece, then I’ll move on to something else. Really I will.

Lessig argues that one kind of DRM is less harmful than another. He says

To see the point, distinguish between DRM systems that control copying (copy-protection systems) and DRM systems that control who can do what with a particular copy (“token” systems that Palladium would enable). Copy-protection systems regulate whether machine X can copy content Y. Token systems regulate whether, and how, machine X is allowed to use content Y.

The difference can be critical to network design: if a technology could control who used what content, there would be little need to control how many copies of that content lived on the Internet. Peer-to-peer systems, for example, depend upon many copies of the same content living in many different places across the Net. Copy-protection systems defeat this design; token systems that respect the network’s end-to-end design need not.

This relies on the assumption that copy-protection systems would be implemented in the network rather than in the end-hosts. From an engineering standpoint, that assumption looks wrong to me.

Consider a peer-to-peer system like Aimster. (I know: they have changed the name to Madster. But most people know it as Aimster, so I’ll use that name.) Aimster runs on end hosts, and it encrypts all files in transit. Assuming Aimster does its crypto correctly, a network-based system has no hope of knowing what is being transferred. It has no hope even of identifying which encrypted connections are Aimster transfers and which are not. Any network-based copy- or transfer-prevention system will be totally flummoxed by basic crypto. Even Secure HTTP will defeat it.

If copy-protection is to have any hope at all of working, it must operate on the end hosts. It must try to keep Aimster from running, or to keep it from getting access to files containing copyrighted material.

I am making a classic end-to-end argument here. As the original end-to-end paper says,

In reasoning about [whether to provide a function in the network or in the endpoints], the requirements of the application provide the basis for a class of arguments, which go as follows:

The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible….

We call this line of reasoning against low-level function implementation the “end-to-end argument.”

Ironically, my end-to-end argument contradicts Lessig’s end-to-end argument.
How can this happen? It’s not because Lessig is a heretic against the true end-to-end religion. His argument is based just as firmly in the end-to-end scriptures as mine. The problem is that those scriptures teach more than one lesson.

(I’m currently working on a paper that untangles the various types of end-to-end arguments made in tech/policy/law circles. The gist of my argument is that there are really three separate principles that call themselves “end-to-end,” and that we need to work harder to keep them separate in our collective heads.)

Lessig/DRM/Palladium Summary, at Copyfight

Donna Wentworth offers a pithy summary of the commentary on Lessig’s DRM piece, over at Copyfight.