Sometimes you scare me
Brendan wrote:
maybe you tell a CRON daemon to start 5 copies of you in 2 seconds time
Wouldn't this at most exhaust the resources of the job in which the CRON daemon is running?
Quote:
maybe you inject key-presses into the keyboard buffer and "exit()" so that if you were started by something like bash then bash gets those key-presses and starts 2 copies of you as background jobs
This would of course require the ability to manipulate the keyboard buffer, which would be another vulnerability. But I guess it would at most exhaust the resources of the job of the bash process. Indeed, a background job should be an own job with it's own resources, but the job system should be hierarchical in the sense that if one job creates another job, the old job can only grant resources to the new one that it owns.
Quote:
maybe you tell the OS that you're a file system driver for "XYZ file system" and give it a dummy disk image/file (containing several partitions formatted as "XYZ file system") and let the OS auto-mount those file systems (where each of those file systems happen to contain a dummy disk image/file containing more partitions for the OS to auto-mount, which....)
Quote:
Maybe you pretend to be a driver for a USB hub (that has many "virtual USB hubs" connected, that each have...)
It looks like these ones rely on another vulnerability - telling the OS that you are a driver. Well, I don't have a good idea what to do against this vulnerability (apart from "signed drivers" or the like). But anyway, wouldn't this again be solved by hierarchical jobs, where each device driver can use at most the resources that the driver of the parent device owns?
Quote:
Maybe your process is used by Apache (via. CGI) whenever someone asks for the web page "http://localhost/foo.html", where your process asks Apache for the web page "http://localhost/foo.html" itself.
That would most certainly exhaust the resources of Apache's job and thus "SDOS" (self denial of service!) the web server.
Quote:
Maybe it's just a simple trojan thing - e.g. "This game needs fork permission so the client can start a server process for single-player games"
Quote:
Maybe there's a way to trick the GUI into thinking that the user clicked on the "OK, let this process have fork permission" button in the dialog box; where the application's installer clicks the button before the user has time to see it
These ones would of course defeat the permission system, where processes need a fork permission. In the job based system there would be no such permission, every process may fork, provided it still has resources in its job.
Login
Register
FAQ
Search
