On Tue, 2004-12-21 at 14:34 -0600, milw0rm Inc. wrote: > /* > Two points. > Regarding local versus remote, look at it this way: You have a 100% > secure system. Then you install NASM. Now a user FROM THE NETWORK can > send you some tainted assembly code for you to assemble and he can > compromise your account. > */ > > quote "for you to assemble" > > Its a user error. Your not remotely exploiting anything but the trust > from the user. Although I agree with you that in the vast majority of cases this exploit would require user interaction, there are corner cases where this can be successfully exploited remotely: * gentoo systems by compromising one of the master servers (or more simply by hijacking the connection to one of the those servers) to serve the malicious file - but in this case you probably don't really need this exploit to compromise the system. * other automated build systems (no generic name comes to mind) which download the files they work on from other systems - which may not be trusted to the point that grants a shell but just enough to provide input. * compromising any open-source software's repository that already uses nasm and placing the exploit file in the default build target - tough, but not impossible (it has happened before and will happen again). I guess this is just not "remotely expoitable" in the usual sense (direct attack vector) A.M > > //str0ke >
