Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Advertise on LowEndTalk.com
SECURITY NOTICE : Update Dropbear in Deb6 Stable from Deb6 Testing
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

SECURITY NOTICE : Update Dropbear in Deb6 Stable from Deb6 Testing

rajprakashrajprakash Member
edited April 2012 in Tutorials

Dropbear home page
http://matt.ucc.asn.au/dropbear/dropbear.html

"Security update 2012.55 — releases from 0.52 to 2011.54 are potentially vulnerable to code execution as root by an authenticated user if a command="..." option is used in authorized_keys. Release 2012.55 fixes the problem."

Debian stable (squeeze) is running Dropbear sshd v0.52.
Debian testing (wheezy) includes Dropbear sshd v2012.55

Luckily, you can install Dropbear sshd v2012.55 from the testing repo on your stable system without breaking anything.

Short version
1) Add testing to your /etc/apt/sources.list
2) Create an /etc/apt/preferences file that tells apt the priority order for version control between stable, testing, unsable.
3) apt-get update
4) apt-get install dropbear/testing

Long version
Read and learn :)
http://jaqque.sbih.org/kplug/apt-pinning.html

Have fun and stay safe kids!

Credits go to John H. Robinson, IV jaqque@debian.org for the doc on apt pinning.

Thanked by 3yomero Steve81 mrm2005

Signatures are to identify who I am. I'm me. Who the hell are you?

Comments

  • More good reading to compare dropbear package dependencies between stable and testing ...

    http://packages.debian.org/squeeze/dropbear

    http://packages.debian.org/wheezy/dropbear

    Signatures are to identify who I am. I'm me. Who the hell are you?

  • Thanks rajprakash.

    Maybe compiling from source can be better :P

  • thanks for the info! updating right now...

    Quis custodiet ipsos custodes?
    https://raymii.org - https://cipherli.st
  • Done
    Thank you :)

  • @rajprakash said: "Security update 2012.55 — releases from 0.52 to 2011.54 are potentially vulnerable to code execution as root by an authenticated user if a command="..." option is used in authorized_keys. Release 2012.55 fixes the problem."

    Could someone explain that, as I don't understand it please?

    Thanked by 1bijan588

    Ponies are g&y.

  • mjjohnsonmjjohnson Member
    edited April 2012

    If you want to use your private key to connect to an SSH server (usually a better option than a password), you upload your public key to a file on the remote server; it usually goes in ~/.ssh/authorized_keys, though it can be named something else if you customize your settings in /etc/ssh/sshd_config. Each public key you want to accept is put on its own line, and at the beginning of the line you can specify options that apply to that specific key.

    The command="[command]" option can be used to force a specific command to be run when a user connects; they can't do anything else (e.g., can't get a general shell, can't run any other command they specify). It can actually be kind of tricky to really lock this down (see this O'Reilly chapter for examples of how to use it, or this cached version since O'Reilly is under maintenance right now), but it can be a useful option for limiting access and increasing security. Apparently there was a bug in dropbear related to this option.

    For more information, you can search for forced command ssh and there are some good examples/information out there.

    Thanked by 1djvdorp
  • sleddogsleddog Member
    edited April 2012

    Using "command=" in authorized_keys is a custom configuration, which only you (or a user on your system) would have put in place. Look for it:

    [[email protected]:~] grep command /home/*/.ssh/authorized_keys
    [[email protected]:~] 

    And for the root user:

    [[email protected]:~] cd /root/.ssh
    [[email protected]:~/.ssh] grep command authorized_keys 
    [[email protected]:~/.ssh] 

    If you don't find any instances, don't get your knickers in a knot. There will probably be an updated dropbear package in a few days.

    Thanked by 2yomero marrco
  • lbftlbft Member

    The fix for this is now in squeeze (stable).

  • ramnetramnet Member, Provider

    Seeing as packages in Debian Testing receive no security updates whatsoever (aside from whatever happens to trickle down from Debian Experimental), you should never be upgrading to anything in Debian Testing from Stable for a security fix.

  • lbftlbft Member

    Considering just how long it took from the backported fix being prepared by the package maintainer on 28 Feb to the i386/amd64 packages being uploaded to squeeze (some time over the past few days) I think, in this particular instance, moving to a newer version wouldn't have been an unreasonable decision if you were affected by the bug.

    Dropbear is a relatively obscure program and so it misses out on some of the attention that more popular stuff gets. One thing I've learned now is that Debian security support is not all that it's cracked up to be.

  • rajprakashrajprakash Member
    edited May 2012

    Agree. That's exactly why I upgraded from testing.

    Signatures are to identify who I am. I'm me. Who the hell are you?

Sign In or Register to comment.