- This topic has 17 replies, 6 voices, and was last updated Jan 23-1:19 am by ex_Koo.
-
Posts
-
Anonymous
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
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.
antiX with runit - leaner and meaner.
dolphin_oracle
update showed up yesterday, thanks skidoo!!!
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 installfixed 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
BitJam
(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.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-passBitJam
@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:
https://github.com/gapan/gnsu
https://github.com/sparkylinux/sparky-suRealization 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.
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, postinstRemoval 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 -0300On 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 gksuNope, 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.
/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 1the 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?
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&>1and 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.
a 2021 followup post, motivated by the discussion here:
https://www.antixforum.com/forums/topic/timeshift-doesnt-work-with-antix/page/2/#post-50406under active development? What remains to be “developed”???
An eventual future version will bear a gtk3 gui instead of gtk2, but I’ve grown weary from inherited “tales of purported vulnerability” and related misinformation. Therefore, the future release at gitlab.com/skidoo will bear a changed name. antiX and StarLinux(?) and the other few distros that care to distribute it can alias the new name to work with existing scripts or (preferably) embrace the changed name.
“I read on the internet suchandsuch…”
yeah, well, gksu was widely configurable and was configured differently across various linux distributions
(even across releases of same distro, as witnessed in antiX).The gksu version described in this topic, its hardening was achieved by shedding needless (and confusingly configurable) features.
sudo unconditionally serves as the antiX19 gksu backend.
(unconditionally, as in, cannot be “reconfigured” to alternatively use “su”)sudo can be (and is “par for the course” across most desktop linux distros) setup to use an “insecure” configuration.
The absence of a sudoers TIMESTAMP_TIMEOUT=0 declaration is inherently insecure._____________________________
The unreleased version of gksu, which has been in use locally on all the machines I support, it unconditionally disregards any specified “grace period” and visually alerts the user (and demands reauth) EVERY TIME something ~~ e.g. a scripted call ~~ invokes it.
hit-and-run
It is sometimes impossible for an auth mechanism, any auth mechanism, to identify the caller of a currently running process. Example: when someone “F2” uses gexec, enters a commandstring, ticks “asRoot” checkbox, and click OK… gexec instantaneously echoes the commandstring and exits.
-=-
I rely on gksu to automatically, consistently, attempt to grab and display the name and/or path of the the parent process.
Evident in the screenshot within my earlier posts here, it even attempts to recursively getppid() walk the process chain to identify the GRANDparent process.
-=-
Does any other auth front-end program provide such entensively detailed info?
(Nope, didn’t ask “who the heck needs such extensively detailed info?”)
After fairly extensive searching, I could not find such a program so I rolled up my {gender neutral garment} and set to work, coding to scratch my inquisitive itch.I often think of/about the “gexec” program. In contrast, I rarely “think about” the gksu program.
Frankly, I can’t recall the last (most recent) time I launched a command by typing a prepended gksu.
I only wind up using it when occasionally launching something via F2 (gexec) and clicking the “AsRoot” tickbox.
-=-
Hmm, restating the above:
During a desktop session, skidoo often launches via F2 (vs traversing a menu), but seldom has occasion to tick “AsRoot”._____________________________
The sudo configuration (not gksu) governs which environment variables are preserved when launching a program.
gksu uses the same sudo option(s) that you can more quickly type, directly, by calling sudo from commandline.
People who misuse sudo (due, in part, to misunderstanding/ignorance) are prone to also misusing gksu.
Here in one of the forum topics, I posted a screenshot of the (“bright orange and rainbows”) garish window theme that I preconfigure for rootyroot use on the machines I support. It serves as a reminder to users ~~ “if yer sportin’ clown colors, you look like a clown”.
- You must be logged in to reply to this topic.
