Announcement

Collapse
No announcement yet.

OpenSSH Clients Struck By New Security Vulnerability

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

  • #21
    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; 15 January 2016, 10:28 AM.

    Comment


    • #22
      Originally posted by wagaf View Post

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

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

      Comment


      • #23
        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 )

        Comment


        • #24
          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.

          Comment


          • #25
            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

            Comment


            • #26
              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; 15 January 2016, 09:39 PM.

              Comment


              • #27
                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.

                Comment


                • #28
                  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.

                  Comment

                  Working...
                  X