Quote from: bitlotto on June 17, 2011, 10:11:10 PM

Quote from: enmaku on June 17, 2011, 10:03:49 PM

Quote from: bitlotto on June 17, 2011, 10:00:31 PM

Quote from: DukeOfEarl on June 17, 2011, 09:52:51 PM

Just wait until the first buffer overflow exploit in the client. Then things will really get interesting.

Interested. Explain.

By giving an application carefully malformed input which is larger than the field it was expecting you can sometimes cause your malformed input to overwrite part of the copy of the application that is sitting in active memory, effectively rewriting some of its code to your own ends. This means that one could, for example, rewrite the code that sends BTC substituting whatever variable holds the recipient's address with a static wallet address, so it would look like you sent person A coins but actually sent them to attacker B.

Buffer overflows are very scary, but they're also pretty hard to pull off in a meaningful way. I don't expect to see many such exploits in the wild any time soon.

Ok, but for most users the only place that would occur would be the address input or amount right? (I know just a tiny bit about buffer overflows) The address would have to be pretty malformed to work right? I guess if you're opening bitcoin with a script it would be easier...

I think that's the idea, scripts like this one are popping up more and more often. People like the ease of use that a one-click payment option offers, but it can also lead to deliberate attacks on the client itself. It would also be possible for programs on the same local machine to attempt to overflow the bitcoin client through input methods not normally used by humans (like RPC) or even just directly manipulate its memory space.