On Tue, Dec 21, 2004 at 02:34:20PM -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.
>
> //str0ke
Would you also argue that if someone views a web page and is compromised
because of a bug in the HTML parser of their web browser, it is their fault?
Certainly, assembling and then executing code of unknown provenence is a dumb
idea. But at the point you assemble it, it is just ASCII text. There is a big
difference between running code that you don't know, and running code you do
know on potentially malicious data. The first might be asking for it, but you
do the second every time you connect to a network.
> /*
> 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.
>
> //str0ke
Would you also argue that if someone views a web page and is compromised
because of a bug in the HTML parser of their web browser, it is their fault?
Certainly, assembling and then executing code of unknown provenence is a dumb
idea. But at the point you assemble it, it is just ASCII text. There is a big
difference between running code that you don't know, and running code you do
know on potentially malicious data. The first might be asking for it, but you
do the second every time you connect to a network.
Jack
[ reply ]