patched gksu + libgksu available

Forum Forums antiX-development Development patched gksu + libgksu available

This topic contains 13 replies, has 5 voices, and was last updated by skidoo Apr 20-12:25 am.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #18627
    Member
    Avatar
    skidoo

    packages gksu and libgksu have been removed from Debian testing repositories
    and will absent from Debian10 Buster. The cited reason, by “Debian Gnome Team” maintainers
    (primarily, Jeremy Bicha) is that gksu is “unsafe”.

    UNSAFE because debian (and upstream guh-nome) had allowed the following vulnerability to languish, unpatched, since 2014

    https://nvd.nist.gov/vuln/detail/CVE-2014-2886
    GKSu 2.0.2, when sudo-mode is NOT enabled, uses ” (double quote) characters in a gksu-run-helper argument,
    which allows attackers to execute arbitrary commands in certain situations involving an untrusted substring within this argument.

    Because antiX 17 shipped gksu preconfigured to use “sudo mode” (preserves $HOME env) as DEFAULT_MODE
    antiX users were not exposed to the vulnerability.

    // in sudo mode, check for ‘ and \ in string and escape it
    if(run_mode == SUDO_MODE &&
    (strchr(newargv,’\”) || strchr(newargv,’\\’)))

    The vulnerability is easily avoided by sanitizing the passed string unconditionally, regardless of “mode”.

    I’ve patched, built, and tested on (antiX17+Debian9) the following patched packages:
    https://gitlab.com/skidoo/libgksu
    https://gitlab.com/skidoo/gksu

    .

    .

    #18628
    Forum Admin
    anticapitalista
    anticapitalista

    Great! Thanks skidoo.

    I changed format to native rather than quilt and chnagelog with my name in order to get signed debs.
    I built debs for stretch as well as testing(buster) and sid.
    Should hit the repos soon.

    Philosophers have interpreted the world in many ways; the point is to change it.

    #18662
    Forum Admin
    dolphin_oracle
    dolphin_oracle

    update showed up yesterday, thanks skidoo!!!

    #18667
    Forum Admin
    rokytnji
    rokytnji

    Did the update today. Got a error code 1. My bad for not copying error in terminal for this post.

    sudo apt-get -f install

    fixed the error code and completed the dist-upgrade process.

    $ sudo apt-get -f install
    [sudo] password for harry: 
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages were automatically installed and are no longer required:
      ecryptfs-utils libecryptfs1 libtspi1 livestreamer python-appindicator
    Use 'sudo apt autoremove' to remove them.
    0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

    Skidoo gets attaboy from me also.
    `

    Sometimes I drive a crooked road to get my mind straight.
    Not all who Wander are Lost.
    Linux Registered User # 475019
    How to Search for AntiX solutions to your problems

    #18674
    Forum Admin
    BitJam
    BitJam

    Thanks skidoo! This is excellent.

    Context is worth 80 IQ points -- Alan Kay

    #18688
    Member
    Avatar
    skidoo

    (credit to fehlix for pointing this out)
    .
    .
    THE PATCHED gksu IS STILL VULNERABLE TO SURREPTITIOUS EXECUTION OF ARBITRARY COMMANDS WITHIN NESTED SUBSHELLS.
    THE SCOPE OF THIS VULNERABIITY IS EVEN BROADER THAN THE CASE CITED BY CVE-2014-2886.
    THIS VULNERABILITY AFFECTS BOTH “su-mode” AND “sudo-mode” USAGE.

    a demonstration of the problem:

    Issue either of these commands from terminal emulator commandline and note the result

    
    gksu --su-mode echo "hello$(touch /tmp/boom)"
    or
    gksu --sudo-mode echo "hello$(touch /tmp/boom)"

    .

    THE AUTH DIALOG (MISLEADINGLY) DISPLAYS
    the application ‘echo hello‘ lets you modify essential parts of your system
    AND
    regardless of OK // CANCEL choice…
    the file /tmp/boom IS SUCCESSFULLY CREATED

    ==========================================================
    ==========================================================
    ==========================================================

    Now, before further modifiyng the parsing to guard against embedded $( substrings,
    we must investigate whether other characters (backticks? control characters? escape sequences?) could be to used initiate a nested subshell.

    #18734
    Member
    Avatar
    skidoo

    Still testing.
    The following are my notes so far for the next version gksu changelog.

      * gksu.c: addresses possibility of arbitrary command injection via subshell
        ref: CVE-2014-2886
        Escape any backtick characters and any left parenthesis characters
        present within passed string. Guarding left parenthesis also thwarts
        potential injection of  bash_shellfunction_name (somesuch)
        
      * DISABLE the option "--print-pass", aka "-p" which would cause gksu to
         "print the password to stdout, just like ssh-askpass. Useful to use in
          scripts with programs that accept receiving the password on stdin."
        Regardless of any use case where this functionality would be necessary,
        too bad ~~ it also provided opportunity to trick the user into
        having a cleartext password divulged.

    Holler if you can mention a “damned good reason” to NOT disable the option
    −−print-pass

    #18752
    Forum Admin
    BitJam
    BitJam

    @skidoo, I don’t think escaping will be sure to save you but there is an easy solution. The easy solution is to only allow certain characters that we know are safe. Either balk at or remove unsafe characters.

    I am still unclear on when the problem occurs. For example changes to gksu can’t help this:

    gksu --su-mode echo "hello$(touch /tmp/boom)"

    because the double-quoted string is evaluated by the shell when it calls gksu, not by gksu or by echo. But you can protect against:

    gksu --su-mode echo 'hello$(touch /tmp/boom)'

    by cleansing all the input strings. I do something like this for all of the translation strings used in our Bash scripts and our live-initrd. There is really no need for people to be using “fancy” characters like $ and back-tic in arguments to gksu so I think it is safer to just ban them IMO. There is no need to have $ or back-tic in a command name, a command option, or a filename. They have not been needed in any of the translation strings I have cleansed although I have the option of adding unsafe characters using %s with printf. But by doing this they are no longer unsafe.

    ISTM that if you limit the space of characters that are allowed then you can be sure you are safe and IMO the limitation is far from onerous. For the translations strings, all non-literal characters are banned. I think you can use a regex to remove the bad chars (or only preserve the good chars) and then compare with the original string although it might be dangerous to shell out to tr or sed to do this.

    Just my 2 cents.

    Context is worth 80 IQ points -- Alan Kay

    #18822
    Member
    Avatar
    skidoo

    BitJam, I agree that “default deny” (pass only whitelisted characters) is the sane approach.
    Going forward, a bash+yad replacement for /usr/bin/{gksu,gksudo} would be more easily maintainable.
    Still, I’m bent on backporting changes to the pre-existing utility.

    I’ve uploaded to pastebin a list prior art: auth mechanisms, gksu alternatives
    To my dismay, I’ve noticed that most of ’em don’t bother to sanitize the passed string.

    Instilling a false sense of security is worse than providing no security at all !

    Here’s a couple quick examples:
    https://github.com/gapan/gnsu
    https://github.com/sparkylinux/sparky-su

    Realization of this status quo really chaps my hide.
    consider:

    gksu -D "Free puppies!" 'rm -Rf /everything'
    or
    gksu -m "Free puppies!" 'rm -Rf /everything'

    This “use a custom message//description to mask the actual launchstring” behavior
    was introduced back in 2006 (gksu v2.0.1)

    During the past year I have searched and read quite a bit, toward trying to understand the claim(s) that “gksu is unsafe”, and I’ve never seen this particular detail (potential abuse of the options –message and/or –description to obfuscate the launchstring) mentioned. It’s mindbending to realize that for longer than a decade gksu users have been relegated to dutifully jumping through “type your password to authorize” hoops… with ZERO assurance of the actual launchstring they are authorizing.

    #18824
    Member
    Avatar
    skidoo

    Here are some additional changelog notes for the next version.
    Posting these because I realize that my changes may not be amenable to y’all
    ~~ for antiX distribution you might want to just revert to the stock (before my meddling) gksu code.

      * removed "gksu-properties" chooser GUI utility
      * gksu.schemas.in: specify default value "true" for
           <key>/schemas/apps/gksu/sudo-mode</key>
      * debian/gconf-defaults.libgksu-su:
           specify "/apps/gksu/sudo-mode true"
      * dropped inapplicable 01_tcdrain_kfreebsd.patch
      * merged 02_format-security.patch
      * merged 03_makefile_spaces.patch
      * merged 04_automake.patch
      * merged 05_ja.patch
      * merged 06_unguarded_child_stderr.patch
      * merged 13_startup_notification.diff
      * merged 14_polish_startup.diff
      * merged 18_g_markup_escape_text_for_command.patch
      * merged 22_sudo_keep_env.patch
      * merged 23_correct_colormap_get.patch
      * merged 24_cross.patch
      * merged 27_sudo_wrong_pwd_check.patch
      * merged 29_check_newline.patch
      * merged 99_intltool.patch
      * removed redundant debian/pos/pt_BR.po
      * edited debian/README.Debian
           toward (hopefully) rendering it somewhat less nonsensical
      * REMOVED the debian trickery described within debian/README.Debian
           and renamed that file debian/README.Debian_obsolete.
           Removed calls to "update-alternatives" from postrm, prerm, postinst

    Removal of “gksu-properties” will necessitate axing an item from antixcc.sh

    The rationale for its removal is that gksu is (has been) provided soley to cover the “use case”
    of crafting convenient sudo_mode “elevated permissions” launchers.

    Regarging the debian-specific muckery:

    Unless someone has inspected the contents of the source package and read debian/README.Debian
    there’s slim chance that anyone, including the local sysadmin, could determine WHICH END IS _UP_

    ==================
    libgksu for Debian
    ==================
    
    The gksu library enables the user to run programs with root powers
    using one of su or sudo as backend. If the application that uses
    the library doesn't specify the backend it wants to use, the backend
    will be selected through the '/apps/gksu/sudo-mode' boolean gconf option.
    
    The Debian package provides two gconf default files, one of them
    setting sudo-mode to true, the other setting sudo-mode to false. Which
    one of them is used to set the default is decided through an alternative.
    
    Debian tools, Systems Administrators and custom distributions builders
    might want to make use of this functionality to decide whhich backend
    to use. This is done by configuring the libgksu-gconf-default alternative:
    
     # update-alternatives --config libgksu-gconf-defaults
    
     There are 2 alternatives which provide 'libgksu-gconf-defaults'.
    
       Selection    Alternative
     -----------------------------------------------
     *         1    /usr/share/libgksu/debian/gconf-defaults.libgksu-sudo
      +        2    /usr/share/libgksu/debian/gconf-defaults.libgksu-su
    
     Press enter to keep the default[*], or type selection number: 2
     Using '/usr/share/libgksu/debian/gconf-defaults.libgksu-su' to provide
     'libgksu-gconf-defaults'.
    
    After setting the alternative you must run the 'update-gconf-defaults'
    script to actually apply the setting to the gconf defaults XML file.
    
    While this possibility exists, it would be best if it is only used by
    the internal Debian infra-structure, since there are already better
    and documented ways of providing "default" settings for gconf-using
    applications both in the upstream software[0] and in the gconf
    packaging[1] itself, good for administrators and custom distributions
    builders, respectively.
    
    [0]: Read the GNOME Desktop System Administration Guide at
         http://www.gnome.org/learn/admin-guide/latest/
    [1]: See the dh_gconf(1) script provided in the debhelper package and
         also see the /usr/sbin/update-gconf-defaults python script
         provided in the gconf package
    
     -- Gustavo Noronha Silva <kov@debian.org>, Sun,  3 Sep 2006 19:06:47 -0300

    On a pristine antiX17 system, if you checked
    update-alternatives –config libgksu-gconf-defaults
    v— the result doesn’t exactly match those (hidden, and outdated) source docs

    =======================================================
     There are 2 alternatives which provide 'libgksu-gconf-defaults'.
    
       Selection    path_of_Alternative                         Priority    Status
     ----------------------------------------------------------------------------------
     * 0  /usr/share/libgksu/debian/gconf-defaults.libgksu-su     20        auto mode
       1  /usr/share/libgksu/debian/gconf-defaults.libgksu-sudo   20
       2  /usr/share/libgksu/debian/gconf-defaults.libgksu-su     10
    
     Press enter to keep the (current choice, aka) default[*], or type selection number: 2
    ========================================================

    .
    cd /usr/share/doc && find -iname README.Debian | grep ‘gksu’
    man gksu

    Nope, this too-clever nonsense is not disclosed in the installed docs.

    After setting the alternative you must run the ‘update-gconf-defaults’
    script to actually apply the setting to the gconf defaults XML file.

    Who knew this?!? Go ahead, raise your hand…

    .
    .
    .
    update-alternatives –config libgksu-gconf-defaults
    So… as noted in the changelog (“REMOVED the debian trickery”)

    #18838
    Member
    Avatar
    skidoo

    BitJam, the hardening of gksu definitely introduces breakage to various antiX utilities.
    (gksu, or ANY graphical sudo front-end)

    Not all of the following are problematic, but I’m pasting a roundup of examples showing current gksu usage in antiX.

    /usr/local/bin//UM-set
        gksu user-management &
    
    /usr/local/bin//antixcc.sh
        gksu '$EDITOR /live/boot-dev/boot/grub/grub.cfg' &
    
    /usr/local/bin//antixcc.sh
        gksu $EDITOR $EXCLUDES_DIR/*.list &
    
    /usr/local/bin//antixcc.sh
        gksu $EDITOR /etc/fstab /etc/grub.d/* /etc/apt/sources.list.d/*.list &
    
    /usr/local/bin//desktop-defaults-run
        gksu -u root "$Exec $xtraargs $args" 2>/dev/null &
        
    /usr/local/bin//desktop-defaults-run
        gksu -u $(whoami) "$Exec $xtraargs $args" 2>/dev/null &
                   ^--------- wheeeee
    
    /usr/local/bin//edit-as-root.sh
        exec gksu $EDITOR "$@"
    
    /usr/local/bin//inxi-gui
            # Info tool by Misko_2083  # modified by kmathern to use yad
        gksudo "sudo apt-get install inxi -y" | yad --center \
          --progress --title="Installing inxi" \
          --text="please wait" --pulsate --auto-close
    
        gksudo --message 'To run this..blahbla' 'sudo fdisk -l' | tee /tmp/fdiskinfo| yad \
          --center --title="Partition Tables (sudo fdisk -l)" .. \
          --button gtk-cancel:1
    
        gksudo --message 'To run this..blahbla' 'sudo parted -l'|tee /tmp/partedinfo | yad \
          --center --title="Partition Layout (sudo parted -l)" .. \
          --button gtk-cancel:1
    
    /usr/local/bin//rox-as-root.sh
        gksu rox -d "$DIR"
    
    /usr/local/bin//set-desktop-theme
        gksu "$0 --root $args"
        
    /usr/local/bin//set-dpi
        gksu sed -i s/"$var1"/"$var2"/ $FILE2
    
    lib/antiX/antiX-common.sh
        exec gksu -- "$0" "${CMDLINE_ARGS[@]}"
                             ^--------- wheeeeee
                             
    /usr/bin/galternatives  (aka /usr/sbin/galternatives)
        v-------- python
        if os.access ('/usr/bin/gksu', os.X_OK):
        sys.exit (os.system ('/usr/bin/gksu -t "%s" -m "%s" -u root %s' % 
    
    /usr/bin/network-config
        system("gksu /usr/bin/network-config");
        
    ///spacefm    prepends gksu    for graphical su
    
    /usr/bin/su-to-root
        gksu -u "$PRIV" "$COMMAND"
        gksudo -u "$PRIV" "$COMMAND"
        
    /usr/bin/umts-panel
        gksu /usr/bin/umts-panel-configure /home/theUSERhome &
        
    
    /usr/sbin/dkms
        for getroot in su-to-root gksudo kdesu sudo; do
        gksudo)
    
    /usr/sbin/pppoeconf
        exec gksu "$0" "$@" || exit 1
    #18986
    Member
    Avatar
    skidoo

    the double-quoted string is evaluated by the shell when it calls gksu, not by gksu

    /usr/local/bin/set-desktop-theme
    gksu “$0 –root $args”

    /usr/local/bin//antixcc.sh
    gksu ‘$EDITOR /live/boot-dev/boot/grub/grub.cfg’

    So, from the earlier list, these 2 are the only current usages which will be “broken, in the presence of SAFE gksu”, right?

    #18990
    Member
    Avatar
    skidoo

    only allow certain characters that we know are safe. Either balk at or remove unsafe characters.

    Continued testing has indicated that only these FOUR must be treated as dangerous characters:
    backtick
    dollarsign $
    backslash \
    left parenthesis (

    .
    The drafted DESCRIPTION portion of the revised gksu (aka gksudo) manpage states
    and same is reiterated within the –help message:

    DESCRIPTION:
    As of version 2.1.1, gksu and gksudo identically provide a graphical frontend to __sudo__.
    Their purpose is to enable you to run graphical commands that require elevated
    permissions, without the need to use sudo directly.

    If no command is given, the gksu program will display a small “Run program”
    window that enables you to type in a command to be run
    ______________________________________________________________________

    IN ORDER TO ENSURE ‘INFORMED CONSENT’, DURING EVERY INVOCATION
    >>>>> IRRESPECTIVE OF ANY CONFIGURED SUDO(ers) TIMEOUT <<<<<
    gksu (or its alias, gksudo) PRESENTS A POPUP
    DISPLAYING THE TO-BE-AUTHORIZED COMMANDSTRING AND REQUESTING PASSWORD ENTRY.
    This behavior is ‘by design’ and is non-configurable.
    ______________________________________________________________________

    Another ‘by design’ behavior: gksu guards against potential keyloggers.
    With every invocation, gksu attempts to grab mouse, screen, and keyboard.
    Because the grab operation may not succeed under certain window managers,
    gksu will warn if the grab operation fails.

    Its role (which, across years, has been misappropriated) should include a providing safeguard,
    an opportunity for inspection ~~ accurately presenting the actual sudo commandline
    which the user would have, in the absence of gksu, provided directly in a terminal.

    Thwarting potentially malicious redirection is beyond the scope of gksu
    <<
    2&>1

    and in fullfilling its role effectively, gksu need not find prejudice against globbing-related characters
    [ { ^ ? *
    nor additional “special” bash characters
    | & ~
    : as [:alnum:]

    #20591
    Member
    Avatar
    skidoo

    The list of blacklisted characters is less restrictive than the set used in the recent gexec release.
    Here, the emphasis is toward ensuring WYSIWYG “informed consent”.
    Prior to uploading a betatesting release, I’m open to suggestions ~~ for example:

    if { left curly brace were disallowed, no possibility of parameter expansion, so the percent character would be harmless

    The “fullpath” details, available in the logfile…
    suppressing them from display would reduce clutter within the popup.

    .

    Within the dialogs + popup, all the strings are gettext translatable
    and the commandline parsing is expected to properly handle any UTF-8 characters within filenames.
    The manpage is reasonably verbose (2-3 screensful) but is English only.

    .

    .

    .

    .

Viewing 14 posts - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.