21–30 of 38 posts
Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
Managed languages are very susceptible to timing attacks.
Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
If OpenSSL was written in a managed language, someone would need it in an environment a managed language wasn't suitable for, and end up porting it to C.
Is it me or should code that has to be secure be written in more manage languages to prevent these mistake ? (But managed languages probably have other security issues I don't know about ?)
Managed languages is one way to go, but they are not really appropriate for performance critical libraries like OpenSSL in my book. You can get safety without being managed in modern languages if the compiler does the safety proving for you (e.g. rustlang).
This is complete bullshit. Please cite where you found these results. Even if this was true, since the servers also run openssl, you'd be able to at least run a client at 10x/100x/1000x the speed of the server (because the client doesn't have to have concurrent connections), which would make the "slow managed code" fine for a client.
Good to note that this was found with KLEE[1]. KLEE is a good for symbolic execution of code and is very cool[2]. This only triggers a crash if you use RELEASE_BUFFERS (not the default) and a warning alert is written when the socket buffer is full. About the only case where a warning alert is generated is when a client attempts a renegotiation without the renegotiation extension (unless insecure renegotiation is allo…
Here is an example of its power and how to use it: http://feliam.wordpress.com/2010/10/07/the-symbolic-maze/
Good to note that this was found with KLEE[1]. KLEE is a good for symbolic execution of code and is very cool[2]. This only triggers a crash if you use RELEASE_BUFFERS (not the default) and a warning alert is written when the socket buffer is full. About the only case where a warning alert is generated is when a client attempts a renegotiation without the renegotiation extension (unless insecure renegotiation is allo…
Are there any write ups for this yet? I can't find a CVE or anything on this one. No word from OpenSSL yet either.
This shouldn't be exploitable on modern linux machines due to https://wiki.debian.org/mmap_min_addr Who knows for embedded devices.
Good to note that this was found with KLEE[1]. KLEE is a good for symbolic execution of code and is very cool[2]. This only triggers a crash if you use RELEASE_BUFFERS (not the default) and a warning alert is written when the socket buffer is full. About the only case where a warning alert is generated is when a client attempts a renegotiation without the renegotiation extension (unless insecure renegotiation is allo…
KLEE is ok on small programs but has a lot of limitation with real world programs (using libraries mostly) at least according to a USENIX paper last year: https://www.usenix.org/conference/cset13/workshop-program/pr...