Attack Vector - libraries ?

[Herodes]

I tried to find information about this by searching the forum and google quickly, but it didn't turn up anything.

Specifically I'm interested in the danger that rogue libraries may pose in regards to the bitcoin client. It's a while since I compiled the client, but recently I downloaded 0.8 binary to a windows machine and verified that the sha256 checksum was correct, and then also verified that the file containing the checksums was signed by gavin. All turned out well.

However, what if I were to compile it all from the sources, as far as I remember, there's a lot of dependencies, ie. the dev has to download a lot of different libraries to have everything work properly, so I could still verify the download, but when you download libraries, often you can get it from various mirrors, and of course lots of these libraries still can be checked against checksums on their official pages, but say this isn't done properly, is there any chance that there could be anything malicious going on with a library, and this could be used to do a digital heist ?

Forgive me my lack of knowledge in this particular field, but I'm just thinking out loud: Is there any way that a rougue library could cause trouble with the client ?

For example if a library function ever touched a bitcoin-adress, it could be switched to one owned by the attacker. Of course, I could peek at the bitcoin source and make more of an educated decision in regards to this, but I would think there are devs far more involved with the source code that would be able to cast some light on this and whether it is a worry or not.

And also (and this is more relevant to the linux sources), is what is proposed here (https://bitcointalk.org/index.php?topic=152058.msg1614138#msg1614138) more secure than linking libraries dynamically ? And then I'm thinking in terms of both security and bugs.

Also I would think some rogue library could also make it less apparent that there's some attacks going on, as it could just collect information (private keys ) that could be used later on, or only have the malicious behaviour play out sporadically.

I would think most libraries are maintained well, but if anyone downloaded from a mirror and didn't verify the download and then proceeded to use the malicious code to compile the QT-client, then there could be some rogue stuff going on ?

Please enlighten me. Thanks.

[1714617576]

1714617576

[oakpacific]

I think so, but there is no way anyone can account for all the possibly ways people can mess things up.

[theymos]

Libraries are no more or less safe than other software. Security-wise, using the OpenSSL library functions is nearly the same as executing the standalone openssl program in a shell. In both cases, the software could be malicious, and if used it could read keys from memory, etc.

Bitcoin actually has very few dependencies, and they are common libraries that should be secure.

[Herodes]

Bitcoin actually has very few dependencies, and they are common libraries that should be secure.

That's what I thought too, but has anyone gone through and made a list of all the dependencies ?

[theymos]

That's what I thought too, but has anyone gone through and made a list of all the dependencies ?

For the minimal bitcoind build:
- Berkeley DB
- Boost
- LevelDB (packaged with Bitcoin)
- OpenSSL
- C++ standard library and compiler

[Mike Hearn]

This is something that I worry about for bitcoinj where there are more dependencies and they're automatically downloaded at compile time by Maven. I've asked a few people to look at adding hashes to the dependency definition which should make it harder to attack, but really, the entire dependency tree needs to be fixed like that.

Over time this is something that will get more attention.

[Herodes]

This is something that I worry about for bitcoinj where there are more dependencies and they're automatically downloaded at compile time by Maven. I've asked a few people to look at adding hashes to the dependency definition which should make it harder to attack, but really, the entire dependency tree needs to be fixed like that.

Over time this is something that will get more attention.

What's your opinion about statically linking libraries vs. dynamically linking it in the binaries in terms of security ?

Would it also be possible to go through the code where it does external calls and figure out if there could be any places were the risks could be bigger, I mean - if a bitcoin address is passed to a function in a library, the danger is bigger, as opposed to a function that merely draws a window on the screen.

Perhaps we'll even se a fork of the client for the paranoid. Paranoid Qt-bitcoin client. hoho.