On 9 April 2014 06:35, Jonathan Ryshpan <jonrysh(a)pacbell.net> wrote:
On Tue, 2014-04-08 at 10:55 +0100, Patrick O'Callaghan wrote:
>
https://www.openssl.org/news/secadv_20140407.txt
>
> See also
http://heartbleed.com/ and
>
http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-op...
>
> This is potentially very serious and can cause leakage of private keys
> and other information.
>
> The current version of OpenSSL on Fedora (standard repos and Koji) is
> 1.0.1e, which has this vulnerability. An upgrade to 1.0.1g should be
> provided urgently.
There's a front page article in the NY Times about this, first time ever
seen an article there about a technical subject.
It's an interesting question why Net infrastructure code continues to be
written in C, a language that provides no automatic checks for buffer
overflow, which (if I understand right) is the opening for this security
breach, along with so many others. And why is the code run on hardware
that provides no such checks? There have been languages and system that
check for overflow available for 40 years. Why doesn't anyone use them?
People use them, but not for everything. Particularly a read buffer
overflow is harder to detect anyway (and a program needs to access its
own memory space). A few reasons for C to persist in applications like
this:
* Performance. We can get into long arguments about Java JIT compilers
(see next point) but most alternatives don't meet the performance
needs.
* Availability. C is the best common denominator for coding on many
different platforms. (Note Java, Python, Perl, PHP are all used for
'Net infrastructure code', mostly at a higher level.)
* Interoperability. Often overlooked, it's easier to provide bindings
for other languages to C libraries.
- all the above apply in a slightly weaker form for C++.
It is possible to write safe C code, and this has been increasingly
done since these programmes have been exposed to increasing attack
pressure.
--
imalone
http://ibmalone.blogspot.co.uk