Announcement

Collapse
No announcement yet.

OpenSSH Clients Struck By New Security Vulnerability

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic OpenSSH Clients Struck By New Security Vulnerability

    OpenSSH Clients Struck By New Security Vulnerability

    Phoronix: OpenSSH Clients Struck By New Security Vulnerability

    Any OpenSSH client released in the past six years is prone to two vulnerabilities by malicious SSH servers that could cause memory disclosures and a buffer overflow...

    http://www.phoronix.com/scan.php?pag...SH-Client-Woes

  • rmiller
    replied
    Originally posted by RavFX View Post
    Disabling a feature is not a fix.

    I use this feature a lot thanks to the crappiness of my Internet connection.
    Impossible! The matching server code has never been shipped. So, no feature was removed.

    Leave a comment:


  • Ardje
    replied
    Originally posted by RavFX View Post
    I did not know this one. I will try it.
    It also exists as a chrome plugin (for chromebooks) and as protocol in juicessh (android).
    For interactive purposes it works so much better than ssh, especially on bad connections. But it actually is just that, a very good kind of screen.

    Leave a comment:


  • SystemCrasher
    replied
    Originally posted by OneTimeShot View Post
    Should I point out that this is from the people behind LibreSSL who were complaining extremely loudly about how completely incompetent the OpenSSL team was?

    ...or maybe computer security is actually hard?
    Still, does not anyhow negates the facts:
    1) OpenSSL api is bad. Proper encryption api for those not aware of crypto? Take a look on crypto_box() in NaCl. That's how you design APIs for clueless noobs right!
    2) Overcomplicated protocol coming with shitload of overengineered options. Heartbleed? Uhm, why the hell they needed to ask remote to send arbitrary amount of bytes in first place? Bugs are what you get for overengineering.
    3) Plenty of legacy and non-secure options.
    4) Rather complicated server & client negotiation. It both harms privacy (it allows some fingerprinting) and leaves chance connection uses insecure options. Not to mention MITMs can do downgrade attacks, and it happened more than once.
    5) Good luck to use OpenSSL securely if you're not cryptographer. Do you know which CAs it trusts by default? (and who can take over your connection, lol). Do you know which algos it could use? Are you sure it would not use "secure" 40-bit RC2?
    6) Some design decisions are really risky and unprofessional ones. If you ask for HW acceleration, these cool devs would feed app with HW RNG output directly. Entropy sources mixing? Uhm, they never heard about it. But wait, even Linux kernel does it. Mixing HW entropy with the rest, so even if there was backdoor, it's not a big deal - entropy quality just does not increases, but not getting worse. And Linux kernel not even being advertised as major crypto library. I think LibreSSL team could do a bit bette than THAT, avoiding such a glaring errors in crypto implementation. It has gone as far as Tor devs being forced to code their own workaround for OpenSSL.

    And while I think OpenSSH security claims are exagerrated (in particular, SSH protocol not very secure on its own and leaks plenty of data about session nature) - overall, security record of OpenSSH server/client is much better compared to OpenSSL. Yet, looking on how they add all sorts of cruft into OpenSSH, it seems they are in mood to "fix" it. Now we have first fruits it brings. I guess there going to be a lot of "fun". Of course as long as you have fun doing emergency patching and rekeying.
    Last edited by SystemCrasher; 01-15-2016, 09:39 PM.

    Leave a comment:


  • DrYak
    replied
    Originally posted by RavFX View Post
    Disabling a feature is not a fix.
    I use this feature a lot thanks to the crappiness of my Internet connection.
    Another thing to consider is "autossh"
    It's a wrapper around autossh that basically does the same kind of things as connection roaming, but does it better (it uses a port-forwarding loopback to constantly poll the connection and tries to reconnect if the connection breaks).

    In lots of Linux distribution, it's available as a standard package. (eg.: in opensuse)

    When combined with screen(*), it's a very nice tool for persistant connections.

    If your main problem is that you connection is slow (2G GPRS), I would suggest mosh.
    If your main problem is that you're constantly getting disconnected, I would suggest autossh + screen

    ----
    (*): screen require terminal emulation. Thus add '-t' option to ssh:
    autossh -M {loopback_port} {server} -t -- screen -Rd

    Leave a comment:


  • caligula
    replied
    Originally posted by philcostin View Post
    Without evangelizing too much, don't write off Ada. Most people consider Ada to be "old" and they don't like it because it uses "begin/end" instead of "{ }" - which is a poor reason, tbh. Bracketing statements with words allows the compiler to check which scope you are intending to leave ("}" vs end if )
    Nowadays {} is old because of Python style clean syntax. The syntax might be one of the main reasons why people like Python.

    Leave a comment:


  • philcostin
    replied
    Without evangelizing too much, don't write off Ada. Most people consider Ada to be "old" and they don't like it because it uses "begin/end" instead of "{ }" - which is a poor reason, tbh. Bracketing statements with words allows the compiler to check which scope you are intending to leave ("}" vs end if )

    Leave a comment:


  • RavFX
    replied
    Originally posted by wagaf View Post

    Have you tried Mosh ?
    https://mosh.mit.edu

    I did not know this one. I will try it.

    Leave a comment:


  • zanny
    replied
    They enable us less capable and technical developers to develop code more efficiently, faster, and with less bugs (security holes too.).
    Except that isn't true. They enable all developers, unless you are circlejerking C out your ass, to code more efficiently, faster, and securely. Regardless of who you are, if your choice is to have either transfer<T>() as your function signature or transfer_int(), transfer_str(), transfer_ptr(), the former will be faster, safer, and more legible. No matter who you are, if your choice is between malloc / free, new / delete, or make_unique / make_shared, the later will always be faster, safer, and way more safer. No matter who you are, if your choice is between struct { int(*compute)(float,double); } foo; and class foo { int compute(float,double) {}}; of course the latter syntax is going to be less error prone and buggy especially when you try to implement inheritance (albeit C++'s multiple inheritance is a disaster, nobody is saying its a pretty or well designed language, if you want that use Rust). Of course wrapping your libraries in namespace libname {} rather than making every function signature some Java-esque monstrocity like GSTREAMER_LIB_READ_IO_BUFFER_WRITER_STAGE2_REBUFFE R(). Its not like you cannot do stupid shit in C. You can still just go try to execute random address space and blow up your program in any line you want. C is simple, but its simple to a fault. Both C and C++ are minefields or exceptional or edge case behavior, but at least one lets you get work done without having a buffer overflow exploit every other month.
    Last edited by zanny; 01-15-2016, 10:28 AM.

    Leave a comment:


  • Djhg2000
    replied
    The point about needing to know what you're doing in C is as true today as it was 20 years ago. You can't just use the trial and error approach to writing your code because you'll end up with plenty of bad practice code. This is especially true when combined with networking.

    Leave a comment:

Working...
X