patched gksu + libgksu available

Forum Forums antiX-development Development patched gksu + libgksu available

  • This topic has 13 replies, 5 voices, and was last updated Apr 20-12:25 am by skidoo.
Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
  • #18627

    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
    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:



    Forum Admin

    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.

    antiX with runit - leaner and meaner.

    Forum Admin

    update showed up yesterday, thanks skidoo!!!

    Forum Admin

    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.
    I'm not outa place. I'm from outer space.

    Linux Registered User # 475019
    How to Search for AntiX solutions to your problems

    Forum Admin

    Thanks skidoo! This is excellent.

    Context is worth 80 IQ points -- Alan Kay


    (credit to fehlix for pointing this out)

    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)"
    gksu --sudo-mode echo "hello$(touch /tmp/boom)"


    the application ‘echo hello‘ lets you modify essential parts of your system
    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.


    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

    Forum Admin

    @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


    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:

    Realization of this status quo really chaps my hide.

    gksu -D "Free puppies!" 'rm -Rf /everything'
    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.


    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
      * specify default value "true" for
      * 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

    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
    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
    [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 <>, 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”)


    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.

        gksu user-management &
        gksu '$EDITOR /live/boot-dev/boot/grub/grub.cfg' &
        gksu $EDITOR $EXCLUDES_DIR/*.list &
        gksu $EDITOR /etc/fstab /etc/grub.d/* /etc/apt/sources.list.d/*.list &
        gksu -u root "$Exec $xtraargs $args" 2>/dev/null &
        gksu -u $(whoami) "$Exec $xtraargs $args" 2>/dev/null &
                   ^--------- wheeeee
        exec gksu $EDITOR "$@"
            # 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
        gksu rox -d "$DIR"
        gksu "$0 --root $args"
        gksu sed -i s/"$var1"/"$var2"/ $FILE2
        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' % 
        system("gksu /usr/bin/network-config");
    ///spacefm    prepends gksu    for graphical su
        gksu -u "$PRIV" "$COMMAND"
        gksudo -u "$PRIV" "$COMMAND"
        gksu /usr/bin/umts-panel-configure /home/theUSERhome &
        for getroot in su-to-root gksudo kdesu sudo; do
        exec gksu "$0" "$@" || exit 1

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

    gksu “$0 –root $args”

    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?


    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:
    dollarsign $
    backslash \
    left parenthesis (

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

    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

    gksu (or its alias, gksudo) PRESENTS A POPUP
    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

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


    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.