|
Boost : |
From: Richard Peters (r.a.peters_at_[hidden])
Date: 2004-12-22 03:41:42
Another argument that I thought of this morning: suppose we do not publish a
self-extracting executable. What is going to stop an attacker from not
uploading his own self-extracting look-alike? If he can change existing
archives, he probably can add other archives as well.
And against what adversary do you wish to defend yourself? If I download an
executable, I run it, and nothing happens, I start investigating, and will
probably figure out what has happened in a short period of time. This is one
kind of attacker: one that just replaces (or adds) his own executable to the
list of available archives. But consider this other attacker: one that takes
the original .zip archive, adds his executable in tools/build/jam_src, and
adds a command to build.bat to execute his own executable. I download it,
unpack it, compile bjam and compile the rest. I do not notice anything
strange, so I'm not on the alert. This attacker has a far higher chance of
doing far more damage than the first attacker, but the last attacker didn't
even need executable archives. I'm far more afraid of this last attacker,
but I just can't defend myself from this covert attack.
If the boost distribution was the only executable I would ever have to
download and execute from the internet, then you have a point. But then
again, in that case I would choose for the .zip archive. But reality is that
I download many more executables. If I look at my download directory, I see
ethereal, fineprint, ad-aware, winpcap, winamp, googletoolbar, and so on,
all downloaded and executed in the last few months. It's a risk I'm willing
to take, and it's a risk most people are willing to take. If you really do
not want to take that risk, there's always the .zip archive, which you
extract and of course, before you use it in your project, you check every
source file for hidden backdoors or malicious software.
From: "Rene Rivera"
> Not considering the entire process is the _biggest mistake_ people make
> when attempting to secure something. Attackers will attack the weak
> points, so if you have one weak point your entire process is insecure.
> For examples, horror stories, and more see Greg Schneier's web site and
> research, like the "Applied Cryptography" book.
Bruce Schneier has written excellent pieces about real-life security. While
"Applied Cryptography" is a great book for cryptographers, an even better
choice would be one of his other books, "Secrets and Lies" and "Beyond
Fear". In these books he explains in plain human english the every-day
concepts of security, and how real-life security is so easily broken. On his
website, www.schneier.com, he publishes his monthly newsletter Crypto-gram,
in which he, like in his books, discusses recent news about security things
(this can be real security products, but more often the US government
policies are discussed) in a manner that is understandable without any
knowledge of cryptology. For everyone who is security-consious, these
articles are really a must-read.
best regards,
Richard Peters
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk