NIST publishes 50kish vulnerable code samples in Java/C/C++, is officially krad
SAMATE - Software Assurance Metrics And Tool Evaluation
Welcome to the NIST SAMATE Reference Dataset Project
Veracode - Vulnerability Scanner for Excutable of C, C++, C#, Java
Topic: URGENT: Windows Bitcoin-Qt update - page 3. (Read 28189 times)
I upgraded my client yesterday and suddenly today I noticed I'm getting hit with a SYN flood attack.
Don't know if it's related but it's damn annoying. I've stopped my BTC client temporarily to see what happens.
Don't know if it's related but it's damn annoying. I've stopped my BTC client temporarily to see what happens.
Java/Python/Ruby/Lisp buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
I tried looking it up, but I could only find some random articles about switching to ada, but nothing stating that "C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_" . Can you point to the article claiming that? 
You have to be god-like to not create security vulnerabilities in significantly C/C++ software. 'Direct' buffer overflows can be avoided by littering your code with meticulous boiler plate (and praying you haven't made a mistake somewhere). But integer overflows leading to buffer overflows are so hopelessly trickly that I have no faith in any C/C++ being safe.
Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
Guess what language Java/Python/etc are implemented it. Java buffer overflows simply don't exist... a huge class of exploit eradicated by language choice. And there's a long list of languages immune to buffer overflows (this is mostly a glaring hole in C/C++). Look up US military/intelligence mandates about language choice. C/C++ is so bad that it should be immediately abandoned and _never_ used for _anything_. Why do you think computer security is such a disaster (it was all C/C++ until the recent xss/xsrf/sql havoc - and that too is a design flaw).
Shouldn't you adher to full disclosure policy? This would actually encourage people to update.
If you look a discussion about full disclosure you'll see that much of the discussion is completely moot when the "vendors" of the software are also the discoverers of the issue. There also isn't much more that could be disclosed right now.
If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier Apart from that, a program's security does not depend on the language, it depends on the coding.
I'm using the anonymity patched bitcoin client (https://bitcointalksearch.org/topic/--24784), hope they get their security patches too.
I don't have any info on the vuln or code for the patch. So I'd advise you not to use my patched binaries until the vuln and fix have been disclosed and I can compile new ones.
It actually isn't impossible, just complex enough it hasn't been accomplished yet.
It's impossible in the same way as brute forcing a 128 bit UUID is impossible
E.g. in our relevant universe.(And enough so for the discussion at hand)
It's simply impossible to provable test all possible pathways as soon as you venture beyond Hello World type complexity.
It actually isn't impossible, just complex enough it hasn't been accomplished yet. It's quite possible to write a specialized emulator that follows every possible code-path with "quantum" memory states... 
Shouldn't you adher to full disclosure policy? This would actually encourage people to update.
If you look a discussion about full disclosure you'll see that much of the discussion is completely moot when the "vendors" of the software are also the discoverers of the issue. There also isn't much more that could be disclosed right now.
Updated, i have 0.6rc4 now
I wonder what happens now with older wallets...
I wonder what happens now with older wallets...
only a question of a solo-mining-noob:
does an update effect the number of done shares to find a btc-block?
example: i have done 140.000 shares with 0.5.2
what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?
does an update effect the number of done shares to find a btc-block?
example: i have done 140.000 shares with 0.5.2
what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?
There is no such thing as shares when you are solo mining, so updating won't affect your solo mining income.
I always encourage people to review the git history, but if you spot the fix for this issue— please don't point it out yet (and I will remove posts that do)
Shouldn't you adher to full disclosure policy? This would actually encourage people to update.
0.5.1 (-beta) is *not* safe.
only 0.5.3.1 and 0.6.0pre4 are safe right now. As for next versions, 0.5.4 and 0.6.0 (final) and so on will also be safe.
All bitcoin versions have -beta added in the "About" dialog as a statement about the current phase of the project, not about the current version.
only 0.5.3.1 and 0.6.0pre4 are safe right now. As for next versions, 0.5.4 and 0.6.0 (final) and so on will also be safe.
All bitcoin versions have -beta added in the "About" dialog as a statement about the current phase of the project, not about the current version.
So if I have 0.5.3.1-beta I'm safe?
Yes. 0.5.3.1 is the fixed version of 0.5.3.
What about 0.5.1-beta? (this versioning numbering is quite confusing)
If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.
Or on the (coding of the) language as you stated just earlier Apart from that, a program's security does not depend on the language, it depends on the coding.
I'm using the anonymity patched bitcoin client (https://bitcointalksearch.org/topic/--24784), hope they get their security patches too.
only a question of a solo-mining-noob:
does an update effect the number of done shares to find a btc-block?
example: i have done 140.000 shares with 0.5.2
what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?
does an update effect the number of done shares to find a btc-block?
example: i have done 140.000 shares with 0.5.2
what will be there for me with update to 0.5.3.1 - start at share number 0 - without the 140.000?
Apart from that, a program's security does not depend on the language, it depends on the coding.
All software developers of any experience and educational background will tell you that programs will always have bugs. It's simply impossible to provable test all possible pathways as soon as you venture beyond Hello World type complexity.
Thus it's better to use a programming and execution environment that protects you, as far as possible, when those bugs are found.
Quote
about 3 days ago i was commenting on the language choice.
from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area.
from a software architecture standpoint other languages than c++ would make more sense in such a sensitive area.
This is nonsense. If anything, more advanced languages can have their own vulnerabilities which could bitcoin vulnerable without any mistakes acutally made by the developers. This is almost impossible with a low level language like c++.
Apart from that, a program's security does not depend on the language, it depends on the coding.
So if I have 0.5.3.1-beta I'm safe?
Yes. 0.5.3.1 is the fixed version of 0.5.3.
So if I have 0.5.3.1-beta I'm safe?
Jump to: