[pups] User Mode DoS Attacks (was Re: Issues of AUUGN)

[pups] User Mode DoS Attacks (was Re: Issues of AUUGN)

[Milo Velimirovic]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 760 bytes --]

> But you'd need kernel mode for that; this is a DoS attack (one of the
> first?) launched by a user.

The userland DoS I remember:

main() {
	while(1)
		fork();
}

And in fact I tried it once on the 11/45 I had access to. Not pretty.  
It can be made less disastrous by judicious addition of a wait(); call.

--Milo, wondering how contemporary UNIX will deal with such  
pathological behavior....

--
Milo Velimirović
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA
43 48 48 N 91 13 53 W
--
There's a reason Dennis Ritchie and Ken Thompson have been awarded  
the U.S. National Medal of Technology (1998) and are fellows of the  
Computer History Museum Online. Dave Cutler hasn't and isn't.
"You are not expected to understand this."

[pups] User Mode DoS Attacks (was Re: Issues of AUUGN)

[Bill Gunshannon]

>> But you'd need kernel mode for that; this is a DoS attack (one of the
>> first?) launched by a user.
>
> The userland DoS I remember:
>
> main() {
> 	while(1)
> 		fork();
> }

Typical "Rabbit Program".

>
> And in fact I tried it once on the 11/45 I had access to. Not pretty.
> It can be made less disastrous by judicious addition of a wait(); call.
>
> --Milo, wondering how contemporary UNIX will deal with such
> pathological behavior....

Not necessarily pathological.  I have students do it all the time
in the early parts of the Operating Systems Course.  The only one
it denies service to on contemorary UNIX is the individual who does
it.  Process limits are by user, not by system.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
bill at cs.scranton.edu     |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>

[pups] User Mode DoS Attacks (was Re: Issues of AUUGN)

[Johnny Billquist]

Back in those days, there didn't exist any process limits, except for 
system wide ones... :-)

Another fun exercise that actually hurts systems today, but didn't hurt 
much back then, are programs that allocate a large chunk of memory and 
hit on a single address on each page repetedly.

Talk about thrashing the memory system... :-) But on the PDP-11, you 
don't use demand paging, nor can you allocate that much memory.

	Johnny

Bill Gunshannon wrote:
>>>But you'd need kernel mode for that; this is a DoS attack (one of the
>>>first?) launched by a user.
>>
>>The userland DoS I remember:
>>
>>main() {
>>	while(1)
>>		fork();
>>}
> 
> 
> Typical "Rabbit Program".
> 
> 
>>And in fact I tried it once on the 11/45 I had access to. Not pretty.
>>It can be made less disastrous by judicious addition of a wait(); call.
>>
>>--Milo, wondering how contemporary UNIX will deal with such
>>pathological behavior....
> 
> 
> Not necessarily pathological.  I have students do it all the time
> in the early parts of the Operating Systems Course.  The only one
> it denies service to on contemorary UNIX is the individual who does
> it.  Process limits are by user, not by system.
> 
> bill
> 

[pups] User Mode DoS Attacks (was Re: Issues of AUUGN)

[Tore Sinding Bekkedal]

(oops, sent it off-list - sorry, Milo!)

On Thu, 2006-10-05 at 08:46 -0500, Milo Velimirovic wrote:
> > But you'd need kernel mode for that; this is a DoS attack (one of the
> > first?) launched by a user.
> 
> The userland DoS I remember:
> 
> main() {
> 	while(1)
> 		fork();
> }
> 
> And in fact I tried it once on the 11/45 I had access to. Not pretty.  
> It can be made less disastrous by judicious addition of a wait(); call.
> 
> --Milo, wondering how contemporary UNIX will deal with such  
> pathological behavior....

Speaking for Linux, quite badly, though there are some patches that
allow you to limit forks per user. There's even a bash version,
":(){ :|:& };:", which will infinitely fork off bash processes. (It
defines a function calling itself in the background, and then
immediately launches it)

The max number of processes is not so much a problem as the fact that
they are all draining the system resources. Besides, one is likely to
run out of memory before one hits the max process number in Linux
anyway.

- Tore Sinding Bekkedal