-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 February 2003 06:38 pm, Mark J Roberts wrote: > Jay Oliveri: > > I don't know what to really think, since conveniently most of > > their evidence is under NDA. > > Devising access control and permissions schemes to limit the > capabilities of code processing malicious data is a tricky business. > The question that needs to be constantly asked is, "Exactly what > capabilities does this program currently need?" > > For instance, to play a movie from a file, mplayer needs to do three > things: > > (1) read the file > (2) write to the screen > (3) write to the sound card (4) load plugins (5) Access the RTC (6) Get access to raw video RAM... Shall I go on? :)
> Consider the command: > > wget ftp://user:[EMAIL PROTECTED]/file.mp3 > > Like mplayer, we can specify that it needs to: > > (1) create "file.mp3" and write to it > (2) establish a tcp connection to server.com > > But (2) can be more specific; in fact, security demands that it be. > What if wget is compromised by some malicious server response, and > rather than merely downloading "file.mp3", deletes all your files on > the server instead? > > The FTP commands wget may use must be explicitly specified! > > Now, what is the most generic and powerful way to accomplish these > things? > > One solution: upload a routine to the OS which may be called later. > In the case of wget, the network code, configured at initialization > time to only do what is necessary to download "file.mp3", is > uploaded to the OS, and its capabilities are extended to include > connecting to server.com:ftp. wget then freezes its capabilities, > revoking permanently its ability to upload any further routines or > acquire any further capabilities, and executes normally, making use > of the uploaded networking code when necessary. Er, uploaded to the OS? What would be the point? Uploading code to the local system is unnecessary. Anyway, it could prepare a TCP packet looking like this: USER user PASS password PASV (options) MODE I GET /file.mp3 QUIT and upload it, then close the sending side of the socket, then just listen for server responses. > Of course, if the uploaded code itself is vulnerable to exploits, > the elevated capabilities of the uploaded code may be exploited. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+St5Jx533NjVSos4RAo5KAJ909ioorYV0uaPKeEbgLqd1lCrmbgCgsl9q g7Gims08ObuLMV3O+K5SjkI= =fj+i -----END PGP SIGNATURE----- _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
