Securing your savings wallet

[justusranvier]

Zero surface for remote code execution between machines

The attack surface is  never truly zero. Would you bet your life that it's impossible to craft an audio packet that crashes the decoder in such a way to allow code execution?

That being said it's probably safer than anything in use currently.

[etotheipi]

Zero surface for remote code execution between machines

The attack surface is  never truly zero. Would you bet your life that it's impossible to craft an audio packet that crashes the decoder in such a way to allow code execution?

That being said it's probably safer than anything in use currently.

It's about as good as you're going to get.  There is no default software on any distribution (that I've ever heard of) that executes code based on the content of incoming audio streams.  Serial, on the other hand, some linux distributions have telnet logins enabled by default over serial ports!

[justusranvier]

There is no default software on any distribution (that I've ever heard of) that executes code based on the content of incoming audio streams.

Irrelevant.

Image displaying software isn't supposed to execute arbitrary code based on the content of a JPEG file, but it still happens sometimes.

That you aren't even acknowledging the existence of an entire category of vulnerabilities does not inspire confidence.

Do we really know sound is safe? Has anyone ever tried to crash the Linux sound drivers via malicious sounds sent to the line in port? Maybe the only reason we don't think a vulnerability exists is because until now nobody has ever had a reason to look for one. Even if the sound drivers and ALSA libs are safe, there's still the matter of hardening the decoding software.

If even a task as old and well-understood as transforming a JPEG image into a bitmap can result in arbitrary code execution you can't just assume that sound is safe without at least some kind of testing.

[Foxpup]

Zero surface for remote code execution between machines

The attack surface is  never truly zero. Would you bet your life that it's impossible to craft an audio packet that crashes the decoder in such a way to allow code execution?

That being said it's probably safer than anything in use currently.

It's about as good as you're going to get.  There is no default software on any distribution (that I've ever heard of) that executes code based on the content of incoming audio streams.  Serial, on the other hand, some linux distributions have telnet logins enabled by default over serial ports!

Your software will, if you're not careful about avoiding buffer overflows. Remember, treat all incoming data as hostile and don't assume it is properly formatted (especially with regard to the expected size of the decoded data structures).

[etotheipi]

There is no default software on any distribution (that I've ever heard of) that executes code based on the content of incoming audio streams.

Irrelevant.

Image displaying software isn't supposed to execute arbitrary code based on the content of a JPEG file, but it still happens sometimes.

That you aren't even acknowledging the existence of an entire category of vulnerabilities does not inspire confidence.

Do we really know sound is safe? Has anyone ever tried to crash the Linux sound drivers via malicious sounds sent to the line in port? Maybe the only reason we don't think a vulnerability exists is because until now nobody has ever had a reason to look for one. Even if the sound drivers and ALSA libs are safe, there's still the matter of hardening the decoding software.

If even a task as old and well-understood as transforming a JPEG image into a bitmap can result in arbitrary code execution you can't just assume that sound is safe without at least some kind of testing.

I'm not saying attack surface is exactly 0.00, simply that I'm not aware of any transfer method that has less linkage between the content of the data stream and what code will be executed. (and subsystems of the OS that automatically operate when the link is detected)

If you want to discuss this further, please respond to the thread I linked above.  This would be a good discussion to have there.