Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Thoughts on Worm Design

By Tau in Internet
Mon Jan 27, 2003 at 08:24:54 AM EST
Tags: Security (all tags)

Okay, so an internet worm is running around and wreaking havoc. (Or is it? things seem more or less OK to me...) What worries me is that even such an unsophisticated worm like this could cause this much havoc; try reading some whitepapers on worm design (and throw in some of your own ingenuity) and imagine one of those monsters unleashed upon the internet -- it would not be pretty. Here's my opinions on the matter

Disclaimer: I Am Not A Security Expert (Nor Do I Play One On Bugtraq)

(This was originally a diary but a few people thought I ought to post this as a story. It's my first, so any editorial feedback would be appreciated)

I once thought about the following: Code Red's still around after God knows how many years now (as well as all its Me-Too knockoffs) and you're always hearing of some other worm that's making the rounds. The thing that all of them (except Sircam, I think) have in common is that they're all targeted at one exploit. Now, let's say someone does a bit of research this time 'round. One could look for some fairly fresh Win2K exploits (there's plenty enough of those around) as well as exploits for various UNIX services; Sendmail's got a lot, Apache's had the odd few, although it doesn't run as root, wu-ftpd ... needs no introduction, and so on. We're already talking about a worm that could command staggering numbers of hosts, probably somewhere in the order of a million. Do your research right and target exploits with loads of vulnerable machines and that could well happen.

Of course if you take the approach that the SQL worm takes you'd probably make yourself seriously noticed within a few hours and no static piece of code can withstand concentrated effort to destroy it for very long [1] Now we come onto the second facet of its design:

This part is fairly simple: networking. Most worms are on their own in the wild, however some have taken the approach of forming an IRC botnet. Of course such worms will really not last very long because they've got their central point of failure hardcoded into them. Handy for getting back at that l4m0r ircop who k-lined you for flooding #daves-mp3s but otherwise not really a serious proposition. Instead why not use the existing network that the worms themselves are forming? Think about it, each worm knows who put it there and who it's managed to infect. You now have a complete distributed routing table for effectively sending broadcast commands to your entire worm base. Only that's a bit of a problem because then all it takes is for someone to send a "shut down" broadcast command and there's your wormnet bollocksed.

So you need to assure the wormnet of your identity. Luckily enough that's a long solved problem: public key cryptography. Make a large private key for yourself, and encode the public key into your worm. Now you can send command messages via UDP (so you can spoof the source address and make yourself harder to find) and control your worm net manually if the occasion calls for it: if your identity checks out, each node will feed it forwards and keep its message id in a cache (if it's already recieved that message, it will ignore it). And throw a TTL field in there too for good measure, though we don't care about retransmissions too much so we can set a value of 40000 or something initially. Heck you could even be very sophisticated about it, making each node that has root enter a promiscuous scanning mode and look for the data passing by it; you could even steno it into a JPEG file and unzip it on some webserver somewhere, then wait for some poor schmuck to access it and the first worm to catch sight of the raw data stream. Or something. Holding an RSA key that the entire wormnet understands basically paints a big "I AM THE BUILDER OF THIS WORM" sign on your behind in neon letters, so you clearly need to use a ton of indirection and camoflague when talking to your net. This is left as an exercise to the reader.

Looking pretty evil isn't it? But remember something I said a bit back: "no static piece of code can survive concentrated efforts to destroy it for very long". Now we enter bold new territory: the dynamic worm. I've thought about this a bit and come up with a multipart design for such a worm:

  1. VM Yep, that's right, this bastard's got its own VM. Most people run x86 servers, sure, but there are also other arches such as Sun. Then consider all those Cisco boxes running IIS. Wouldn't having a worm that could command servers and routers alike be nice? Perhaps but then there's always overheads, although Sun has shown that you can get a functional VM into a few tens of kilobytes.
  2. Kernel This is the bit that communicates with the OS -- it can use the OS TCP/IP stack when it can't get root, or it can use its own TCP/IP stack for the various extended features. It can use local root exploits to try to escalate its priviledges. It also attempts to embed itself directly into the kernel where possible and hide its traces. It also tries to attach itself into various system control files and keep itself on that host as long as possible, as well as remaining hidden.
  3. TCP/IP When the kernel can get packet socket priviledges, this can be used for TCP/IP spoofing, flooding, and port scanning. Consider the Paketto Keiretsu stateless port scanner for instance; we could build something like this into the TCP/IP stack and scan nearby networks really really fast. This saves us some time scanning every single host that might support a comprimiseable service.
  4. Algorithm This controls the scanning system. Using a shotgun approach to the problem won't get you very far, instead this could implement a lot of the ideas discussed in the Warhol Worm paper; explicit hit lists for instance, or time bombs a la Code Red. One could infect a load of clearly badly set up machines, then simply lie dormant. Then on the appointed hour, all of them could awaken at once and start attacking the internet proper so it'd look like the attack was coming from everywhere at once. Also a topology cache could be kept so that a fast infect plan could be built and the worm could infect as many hosts as possible in the shortest space of time. Natch, any comprimised routers could be quite helpful here. Or you can even use heuristics; for instance you assign per-subnet weights to each exploit and try the ones that usually work first: this could rip though a heterogeneous cluster in an extremely short space of time.
  5. Command Algorithm's all well and good but sometimes you want to override it. This can be used to intercept and interpret and forward those RSA'ed command packets we were talking about earlier.
  6. Exploits Ah yes, the core of any worm. Each instance of the worm would have a sackload of exploits in it, natch. Throw some zero day unpublished stuff into here for a real nightmare.
This is all pretty huge and some of it could probably be cut (eg the VM idea's probably a little excessive, and having to deal with routers effectively would be quite tricky to pull off). But it gives you an idea at least.

The idea behind the segmented model is that each of these components are interchangeable: the kernel is specific to each OS and the VM is specific to each hardware architecture, for instance. Also you could have several different implementations of the Algorithm component. These are all different Roles: a Win2K Kernel and a Linux Kernel are different roles for the abstract Kernel component to play, as Near Attack, Far Attack and Hitlist Attack all roles for the abstract Algorithm component. Now, for the coup de grace let us add an upload facility to the Command module which lets us insert new Roles into the wormnet on the fly, as well as introducing Versioning so that each Role can be continually updated.

If we have Major versions which always override previous Major versions, and Minor versions which are randomly selected from a pool, we've got a worm which is always being improved, ever learning new attack strategies and having its bugs and idiosyncracies fixed, but also one with loads of similar components with minor variations: eg some instances of MOV R0,0 type instructions could be replaced with XOR R0,R0, small loops could be unrolled and re-rolled and so on. Because every component is replaceable you've got a worm that's becoming very hard to even detect much less stop; a constantly shifting code base makes for quite the moving target.

Of course this worm is looking fairly huge; in the megabyte range, quite probably. While the odd megabyte is chump change for a server sitting on a DS3 connection, you still want to keep your traffic to a minimum. So if you really want to push the boat out and set fire to it you could adopt a generative approach: once an Exploit module conquers a target machine, it simply loads one of each module into the target, which would be significantly smaller, then make a note of that host. As time goes on these nodes can then differentiate: Scout hosts could alert their peers of new networks. Attacker hosts could comprimise new nodes. Repository nodes could keep a bunch of signed modules of different role and minor version and feed them forwards to hosts that are being comprimised. And so on. You'd have to have a time and topology limited trust relationship between these hosts for all of that to work, and while these metrics could be built into the host cache system this is all beginning to get incredibly complicated so it probably isn't worth the hassle.

But it's a thought. Chances are what I've described is far too overweight and complex to be at all rapid or reliable, but if you think along these lines you've got to admit that the worm concept is a whole pandora's box of possible demons whose surface we've really only scratched. Or maybe I'm talking out of my ass, who knows ;) Regardless it's something to think about.

Sidenote: why's nobody written an antiworm that infects vulnerable SQL servers and then just sits there stopping the nasty flooding one from infecting? who cares if it's legal or not, it'd certainly stop the torrent.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o [1]
o Paketto Keiretsu
o Also by Tau

Display: Sort:
Thoughts on Worm Design | 57 comments (39 topical, 18 editorial, 0 hidden)
Clue. (2.00 / 5) (#11)
by tkatchev on Sun Jan 26, 2003 at 02:50:25 PM EST

You can build a "functional VM" using just a single virtual instruction and somewhere around 10-30 lines of code.

   -- Signed, Lev Andropoff, cosmonaut.

Right (2.50 / 2) (#28)
by carbon on Mon Jan 27, 2003 at 02:19:16 AM EST

I guess that's like saying you can build your own programming language by using rot13 on top of ANSI C.

Wasn't Dr. Claus the bad guy on Inspector Gadget? - dirvish
[ Parent ]
No. Please learn some programming. (2.16 / 6) (#33)
by tkatchev on Mon Jan 27, 2003 at 09:03:55 AM EST

You are speaking out of your ass, sadly.

Please go learn a useful craft, since programming is obviously not your strong point.

P.S. Extremely minimal VM's actually serve a useful purpose in real-world applications -- for security though obscurity, for example.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

Show Me the Money (none / 0) (#39)
by BlackHawk on Mon Jan 27, 2003 at 11:59:36 AM EST

Please post an example of this code - it sounds interesting, although I wouldn't call security through obscurity useful...dangerous is more the word that jumps to my mind.

[ Parent ]
Single instruction computer (4.00 / 1) (#40)
by pdrap on Mon Jan 27, 2003 at 12:25:29 PM EST

It's been known for a long time. Make a VM that implements that single instruction, and it can be very tiny.

See a Google Web and Groups search for "single instruction computer"

[ Parent ]

problem... (3.00 / 1) (#46)
by zealtrix on Mon Jan 27, 2003 at 01:12:58 PM EST

You'd need something so that it can access system functions, which either requires more instructions, or special addressing (more VM code).

[ Parent ]
Not really. (4.00 / 1) (#47)
by tkatchev on Mon Jan 27, 2003 at 03:01:59 PM EST

You don't really need to access system calls.

Presumably, your VM will be running inside a larger, custom project; whatever interaction with the OS you need you can simply offload into the project that calls your VM.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

NAND (4.50 / 2) (#49)
by pla on Mon Jan 27, 2003 at 06:31:59 PM EST

Using a combination of NANDs (or NORs, or a few others that lack any familiar names), you can produce any arbitrary boolean function.

Of course, *programming* anything useful for such a machine would take forever, and debugging would drive you completely mad.

The theoretical minimum aside, however, you *can* produce a very functional VM with an extremely tiny instruction set. For example, to use something comparable to x86 instructions, you can easily get away with just MOV, ADD, SHL (accepting negative counts), AND, OR, and NOT, together with some form of memory-mapped IO (the exact nature of which entirely depends on what you wanted to use this for). And perhaps an IMUL and IDIV if the underlying "real" CPU supports them.

Although some of the instructions I mentioned (particularly MOV) get REALLY complicated (on an x86) internally, you don't need a dozen addressing modes or word sizes - limit yourself to 32 bit signed words, and only allow immediate, direct, and indirect addressing modes for MOV, and effectively modeless for everything else (ie, ADD adds memory address 0 to address 1 and stores it in address 2). To avoid the need for assorted fault modes, make memory wrap, clamp out of range numbers to +-2^31, and define division by zero as division by one.

Could you write such a VM in 30 lines of C code? Perhaps. Not too many more, if not. And the result has 100% of the computational power and perhaps 90% of the convenience of programming in plain ol' x86 assembler (ignoring FP, of course).

[ Parent ]
Security-through-obscurity. (none / 0) (#48)
by tkatchev on Mon Jan 27, 2003 at 03:02:47 PM EST

Don't be so closed-minded. Security through obscurity is a very effective anti-piracy measure, for example.

   -- Signed, Lev Andropoff, cosmonaut.
[ Parent ]

EULA (2.80 / 5) (#12)
by imrdkl on Sun Jan 26, 2003 at 03:00:05 PM EST

Why not have a simple user dialog and signup form at installation time?

Nothing new here (4.00 / 3) (#13)
by HidingMyName on Sun Jan 26, 2003 at 03:42:37 PM EST

These are very typical first thoughts of someone who is just getting their first exposure to computer security. These thoughts seem reasonable, but other people are smart too, these areas are all well explored. Try reading Stallings and Anderson's textbooks as a good introduction. Read about the Morris Internet worm (about 13/14 years ago) and Thompson's Reflections on Trusting Trust. See also Bruce Schneier's writings at Counterpane, the work at OpenBSD (Theo De Raadt) and Crispin Cowan's work (Immunix and stackguard).

The idea of anti-worms and anti-viruses is quite old, and has not worked well in practice (since these pieces of software often malfunction and damage the very systems they are intended to protect).

Why this would never happen (3.60 / 5) (#17)
by biggs on Sun Jan 26, 2003 at 07:10:22 PM EST

So why would anybody with this kinda skill and motivation waste thir time writing such a sophisticated worm? I mean vandals tend be to be stupid selfish fools with nothing better to do. Somebody with this kind of skill would probably be too busy doing very well payed jobs. That's why we see and can expect only more stupid poorly thought-out javascript hacks that prey on microsoft vulnerabilities.

"Rockin my 'hell I made it' wetsuit stitch so I can swim in elevators crazy wet through piss" -Cannibal Ox
well.. (5.00 / 1) (#18)
by WetherMan on Sun Jan 26, 2003 at 07:42:38 PM EST

Many people see more than simple vandalism with establishing a network of high speed hosts, bendable to someone's any whim.


[ Parent ]

Why? Simple (4.00 / 1) (#23)
by greenrd on Sun Jan 26, 2003 at 08:23:35 PM EST

So why would anybody with this kinda skill and motivation waste thir time writing such a sophisticated worm?

Think cyber-terrorism. Someone working for Islamist extremists or Rogue States[tm] (or maybe for "Islamist extremists" who themselves are working for Rogue States - whatever).

"Capitalism is the absurd belief that the worst of men, for the worst of reasons, will somehow work for the benefit of us all." -- John Maynard Keynes
[ Parent ]

Jack's quote (none / 0) (#45)
by PrettyBoyTim on Mon Jan 27, 2003 at 01:01:32 PM EST

Say, is that a real Jack Straw quote? If so, do you have a reference for it?


[ Parent ]

well paid jobs... (5.00 / 1) (#27)
by ryochiji on Sun Jan 26, 2003 at 11:15:42 PM EST

>Somebody with this kind of skill would probably be too busy doing very well payed jobs.

Not all of us programmers want to be busy doing very well paid jobs. Some of us prefer challenge and freedom over money, and as a result, some of us write free software (see sig) or, in some rare cases, virii.

IlohaMail: Webmail that works.
[ Parent ]

Boredom? Proof of concept? Because the can? -nt- (none / 0) (#32)
by lemming prophet on Mon Jan 27, 2003 at 08:10:26 AM EST

Follow me.
[ Parent ]
you never know (5.00 / 1) (#34)
by han on Mon Jan 27, 2003 at 10:30:23 AM EST

Building a sophisticated worm network like this would take several man-years, at least. Not only do you need a motivated team of highly skilled hackers, but you have approximately zero chance to get it to work properly unless you do extensive testing on a moderately large heterogenous network. And since you don't want anyone to analyze runaway instances of your pre-alpha worm code, the test network has to be isolated from the internet. All this doesn't come cheap.

Realistically, I believe something really nasty like this could only be made by the cyberwar department of a large military or intelligence organization. Of course, they would not want to cripple the internet in their own country... which can pretty easily be solved by e.g. making the code check the top-level domain or the user's language settings in an infected computer.

Fortunately, most large software projects fail. Even if such a project succeeded, it is very likely that there would be bugs and inefficiencies that the creators didn't have time to fix, or even notice.

[ Parent ]

The Difference Between Knowing and Understanding (none / 0) (#36)
by EXTomar on Mon Jan 27, 2003 at 11:06:27 AM EST

One big reason why people try to "flex" systems in weird ways like this is that they seek to understand the nature of system.

This acedemic curiosity is the difference between knowing what is wrong compared to understanding the system. With understanding you might be able to glean other useful insight like where the system is strong, how to make the system less vulernable, and even how to apply it to other things outside of computers (how about biology?).

Curiosity is a good thing. Just temper it with a little wisdom. Making the perfect worm might be a good academic thing to do but be aware of the consequences if things get out of the lab.

[ Parent ]
History repeats, again. (4.50 / 2) (#20)
by gulfie on Sun Jan 26, 2003 at 07:53:24 PM EST

The original Morris worm (1988)

It all depends on what the objective is. The article goes into more depth on virus like problems. The MS-SQL slammer, does not write anything to disk, so disinfection of a machine just requires a reboot. Keeping it disinfected requires a patch or blocking some network traffic to the box, that never should have been allowed in the first place, or applying a 'patch'.

The objectives for this worm could be any of the following, or something else.

  1. Internet joy riding.
  2. A screw up, just like the original Morris worm.
  3. Bug fixing vigilantes.
  4. Anti Microsoft PR
  5. Pro cyber-anti-terrorist PR
  6. Anti Wells Fargo PR
  7. The visible aspect of someones secret war.

As a note, this worm did very little to defend against getting stopped, and besides network load issues, it did little damage in comparison to what it could have done. Sure, it kicked South Korea off the net and could have started WW III, but that's minor in comparison to deleting all the data in all the infected databases, or worse yet, dumping the sensitive content of these databases into the public domain.

Okay, maybe WW III would be worse than some database corruption.

So the question is, what do _you_ want to do with this hypothetical worm (by the way, even talking about it might now be a felony thanks to the USA-Patriot act).

Even 15 years later, the Morris worm is a good model of a good worm, albeit one with a bug or two. Why get all tricky and smart when it doesn't need to be for most applications? Unless you want to go joy riding in a really tricked out ride.

In our case, and for the foreseeable future, the primary weakness of the internet is that it does not have enough bandwidth to support all of it's connected nodes, passing traffic as fast as they might like. It is the final trump card denial of service attack.

Most public infrastructure is built this way. If everyone turns on all the appliances, lights, fans, and ovens, the electric grid will go down. If everyone turns on all there faucets, bathtubs and flushes there toilets, the water and sewer systems will go down the drain. If everyone decided to go driving, or talk on the phone, or walking on the sidewalk, those pieces of infrastructure would become overburdened and fail to perform to our previous expectations. The internet is no different, it's just easier to get everyone to flush there toilet at the same time.

It's nothing new, it's rather kind of droll. The denial of service attack is the college prank of our internet. Boys will be boys, and there is little that is cost effective to be done about it. Well, save not running Microsoft products and having reasonable security precautions, but why would anyone be so proactive?

Anti-worms (4.25 / 4) (#21)
by swr on Sun Jan 26, 2003 at 07:54:47 PM EST

Sidenote: why's nobody written an antiworm that infects vulnerable SQL servers and then just sits there stopping the nasty flooding one from infecting? who cares if it's legal or not, it'd certainly stop the torrent.

Because in order to be effective, it would need to replicate. Replication alone can cause a flood of traffic. Even if the worm is coded to limit replication (for example, only replicating to servers it recieves a bad-worm probe from) there is always the possibility of unintended consequences.

There was some speculation about the RTM worm of 1988-11-02, that it was never intended to cause any denial of service, and did so only because of sloppy coding. There was check to ensure that only one instance of the worm was running on any given system, but it did not work.

Doesn't need to replicate... (none / 0) (#35)
by CtrlBR on Mon Jan 27, 2003 at 10:41:35 AM EST

A few vigilante shutting down infected machines as soon as they were attacked by them could have greatly lowered the attack scale...

Each IP address was scanned a few hundred times in less than ten hours, so very few people fighting back should have been enough.

Before this Saturday I was actually strongly opposed to that vigilantism thing but now I think it would have been adequate.

To me crashing those flooding machine would have been like breaking and entering an apartment to close the water tap that is overflowing in the others apartments in the building. I.e. a necessary evil.

If no-one thinks you're a freedom fighter than you're probably not a terrorist.
-- Gully Foyle

[ Parent ]
Network Administrators (3.14 / 7) (#24)
by Talez on Sun Jan 26, 2003 at 10:41:41 PM EST

Any network administrator stupid enough to connect a database directly to the internet deserves to have it exploited.

I'm sorry if it seems fair or harsh but if you're too lazy to take basic precautions against the unknown then you deserve everything you get.

Si in Googlis non est, ergo non est

Replication (none / 0) (#55)
by Neolith on Tue Jan 28, 2003 at 12:40:36 PM EST

There are any number of reasons that a SQL Server needs to be connected to the internet, directly or not. Making use of replication on the internet, for one. Now, in this case, if the server were properly firewalled, it would have avoided the exploit, but there are plenty of exploits that go through the traditional 1433 SQL port. Then again, there might be SQL functionality that needs 1434 open, I don't know.

Also, if an employee has the DE version of SQL installed on their laptop, and takes it home with them and plugs it into their cable modem. The next time they jack into the internal network of their company, blammo.

Security and the lack thereof is not as simple as laziness and ignorance, although that often plays a part.

[ Parent ]
In Reply (3.00 / 1) (#56)
by Talez on Tue Jan 28, 2003 at 06:52:18 PM EST

There are any number of reasons that a SQL Server needs to be connected to the internet, directly or not.

There is no reason for a live SQL server to be directly connected to the internet.

Making use of replication on the internet, for one.

VPN from one network to the other between two firewalls. It's not hard.

Now, in this case, if the server were properly firewalled, it would have avoided the exploit, but there are plenty of exploits that go through the traditional 1433 SQL port.

If you open the port it's live. If you need to have them accessible offsite you should route it through VPN. After all, would you replicate possibly sensitive data over an unencypted link? Neither would I.

IMHO there should only be two ways to get to an SQL server. The first should be via an application server of some kind. PHP/Perl applications running on Apache come to mind. The other is through VPN so that your logical position is behind the firewall rather than your logical position being outside of the firewall and leaving the firewall open to attacks via spoofed UDP packets.

I'm sorry but there's absolutely no good reason I can think of for keeping an SQL server directly connected to the net. I run my catalogue system project just fine and the SQL server never touches the net execpt through Apache.

Si in Googlis non est, ergo non est
[ Parent ]

Hmm.. (4.00 / 2) (#29)
by mikael_j on Mon Jan 27, 2003 at 03:07:46 AM EST

Aren't worms like this one the sort of thing that you talk about on IRC at least once a month or so?

We give a bad name to the internet in general. - Rusty

Depends... (none / 0) (#43)
by Tau on Mon Jan 27, 2003 at 12:50:19 PM EST

...who you define as "you". I'm not the Tau on freenode.

[ Parent ]
Usage of the word "you".. (none / 0) (#57)
by mikael_j on Wed Jan 29, 2003 at 06:06:41 AM EST

I used it in the same way that one would use the word "man" in Swedish, perhaps I should have used "one" instead, despite it sounding a bit formal to me..

We give a bad name to the internet in general. - Rusty
[ Parent ]

Curious yellow (4.00 / 3) (#30)
by Cameleon on Mon Jan 27, 2003 at 06:10:26 AM EST

Sounds a bit like curious yellow, a fictitious worm that uses a network of communicating nodes to adapt to attacks, making it very difficult to remove.

Why a VM? (4.66 / 3) (#37)
by zakalwe on Mon Jan 27, 2003 at 11:38:00 AM EST

1. VM

Why? A VM seems of limited usefullness here. Your actual exploit / bootstrapping code will have to be targetted to the machine you're attacking, so really the only thing that will get to run on the VM is the payload (usually pretty small anyway), and possibly the privilege escalation code (though this will generally be specific to one the machine/environment). You end up having to include code to implement the VM for each architecture, but with individually implemented attacks that aren't shared between architectures - all the overhead and none of the advantages. It doesn't seem like you gain anything over a database of code for each specific machine.

Not quite (none / 0) (#42)
by Tau on Mon Jan 27, 2003 at 12:49:21 PM EST

It could be particularly useful for the exploits: given n arches I write n exploiters in WVM: an exploiter per target platform. Without a VM I've got to write n^2 exploiters: an exploiter per launch platform per target platform. Also algorithms and a TCP/IP stack are totally independent of target arch; if you're deploying a brand new algorithm you don't want to have to send out loads of different versions of it, you want to send out one version.

[ Parent ]
No you don't (none / 0) (#44)
by roystgnr on Mon Jan 27, 2003 at 01:01:27 PM EST

Without a VM I've got to write n^2 exploiters: an exploiter per launch platform per target platform.

No, you've just got to compile n^2 exploiters; you only have to write n (or 2n, for the exploits that can't be written with cross-platform Unix+Windows code) of them.

This means that whenever one of your machines successfully exploits a target of a different architecture, you'll have to transfer an entirely different set of exploiters to that target if you want it to keep attacking other computers, but that's what your worm network is for.

[ Parent ]

Not enough cross-platform exploits? (none / 0) (#53)
by bsimon on Mon Jan 27, 2003 at 11:11:15 PM EST

I wonder if you'd have trouble finding vulnerabilities that can be exploited in multiple platforms by the same VM code. Certainly there are a few, but many exploits are tied to a specific OS's API running on a particular CPU type - I guess most buffer overflows are in this class. I'm not sure how the VM would help in these cases.

you have read my sig
[ Parent ]

It would still be tiny. (4.50 / 2) (#38)
by Sap on Mon Jan 27, 2003 at 11:44:58 AM EST

Of course this worm is looking fairly huge; in the megabyte range, quite probably.

Actually, I'd estimate it at 16k.  What makes you think it would be so huge?

hmm! (3.50 / 2) (#41)
by ebatsky on Mon Jan 27, 2003 at 12:35:54 PM EST

You've just described Microsoft Windows operating system. Maybe you could get on their designing team!

armies (4.50 / 2) (#50)
by eudas on Mon Jan 27, 2003 at 06:43:29 PM EST

the whole worm-network-nodes-pushing-data-forward thing reminded me of an Army with its supply lines pushing forward ammo, medical supplies, reinforcements, etc as it advances and occupies new sites.

how would such a worm using this technique defend against counterattacks which could retake a given host, and thereby disrupt its node-pushing supply lines?

"Nothing is on fire, but the day is still young" -- Phil the Canuck

Route around... (none / 0) (#51)
by bsimon on Mon Jan 27, 2003 at 10:54:03 PM EST

That's an interesting metaphor, you'll probably see it in Time magazine someday soon.

At the moment, automated counterattacks are possibly illegal, and are unacceptable to many. And anyway, someone still has to write the anti-worm software in response to an outbreak, meanwhile the worm spreads. Whether the counterattack is automated or not, an ability to exploit multiple vulnerabilities would certainly help prolong the worm's life.

Of course, a worm doesn't need to infect more a small minority of machines to slow the Internet noticeably. It would naturally route around machines that it couldn't infect, and could have plenty of redundancy in the network to route around hosts that it later loses control of. It might even be a better strategy for the worm to NOT attempt to reinfect those hosts, since they're presumably being monitored. The Internet is full of low-hanging fruit...

you have read my sig
[ Parent ]

armchair philosophers (none / 0) (#52)
by eudas on Mon Jan 27, 2003 at 11:01:18 PM EST

it's just that if you think of it as supply bases for a military force, supply base A sends to B sends to C sends to D which is on the front lines, right? so node A sends to B to C to D which is currently infecting a new host... and B and C are in intermediate stages so they still need the data being fed to them. what happens when you counterattack B or C and disrupt/clean them? then the things further up the supply chain are cut off from reinforcements/new code packets so their development is stunted, rendering them ineffective as well... i guess if you route around it then they could start receiving the necessary code packets from other supply bases/infected hosts but that would take some intelligent programming. (of course, to design something like this at all would take intelligent programming, so..)

anyway, it's an interesting metaphor, and one that quite possibly may become useful (and possibly even SOP as information wars develop). military science, information technology, and game theory all roll into one in the future...

"Nothing is on fire, but the day is still young" -- Phil the Canuck
[ Parent ]

now there's a thought in a half. (3.00 / 1) (#54)
by Prophet themusicgod1 on Tue Jan 28, 2003 at 06:44:50 AM EST

i may not be your leetest computer science student, but i definitely am having troubles installing the latest but not first unsuccessful attempt to run an Open Source Operating System - and to hear you speak off about a virus that could install itself - its own OS - as part of a giant network - this'd be a pretty nice option i think, if used for 'good' other than 'evil'...
"I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet."swr
Thoughts on Worm Design | 57 comments (39 topical, 18 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!