Opened 14 months ago

Closed 14 months ago

Last modified 9 months ago

#17727 closed enhancement (fixed)

sudo-1.9.13p2

Reported by: Douglas R. Reno Owned by: Bruce Dubbs
Priority: normal Milestone: 12.0
Component: BOOK Version: git
Severity: normal Keywords:
Cc:

Description

New patch version

Change History (5)

comment:1 by Xi Ruoyao, 14 months ago

What's new in Sudo 1.9.13p2

  • Fixed the --enable-static-sudoers option, broken in sudo 1.9.13. GitHub issue #245.
  • Fixed a potential double-free bug when matching a sudoers rule that contains a per-command chroot directive (CHROOT=dir). This bug was introduced in sudo 1.9.8.

comment:2 by Douglas R. Reno, 14 months ago

From oss-security:


A flaw exists in sudo's per-command chroot feature that could result
in the variable that stores the command being freed more than once.

I believe this is a fairly low-impact bug as the per-command chroot
feature is not widely used.  The bug was caught by glibc's double-free
detection while I was performing some chroot-related testing.  No
one else has reported the bug which leads me to believe it probably
has not been encountered in the wild.

Sudo versions affected:

    Sudo versions 1.9.8 through 1.9.13p1 inclusive are affected.
    Versions of sudo prior to 1.9.8 are not affected.

Details:

    Starting with Sudo 1.9.3, it is possible to specify an alternate
    root directory that sudo will change to before executing the
    command.  For example:

	someuser ALL = CHROOT=/var/www /bin/sh

    will result in /bin/sh being run inside the chroot jail /var/www
    when the specific user runs "sudo sh".

    Sudo 1.9.8 included a fix for a memory leak in the set_cmnd_path()
    function which can result in the "user_cmnd" variable being
    freed twice, but only when processing a sudoers rule that
    contains a "CHROOT" setting.  This does not affect the "chroot"
    Defaults setting.  Only a per-rule "CHROOT" setting will trigger
    the bug.

Impact:

    The bug can only be triggered by a user that has been granted
    sudo privileges using a sudoers rule that contain a "CHROOT"
    setting and the rule must match the current host.  If no users
    have sudoers rules containing "CHROOT" there is no impact.  This
    feature is not commonly used.

Workaround:

    Remove rules from the sudoers file than contain a "CHROOT"
    setting if using an affected version of sudo.

Fix:

    The bug is fixed in sudo 1.9.13p2.

There is no CVE, so I'm not inclined to promote this to Elevated priority.

comment:3 by Bruce Dubbs, 14 months ago

Owner: changed from blfs-book to Bruce Dubbs
Status: newassigned

comment:4 by Bruce Dubbs, 14 months ago

Resolution: fixed
Status: assignedclosed

Fixed at commits

d8cfe00537 Update to liblinear-246.
37fdf49072 Update to enchant-2.3.4.
1f32386381 Update to babl-0.1.100.
306d8b6975 Update to gegl-0.4.42.
aa11d6fcfa Update to ibus-1.5.28.
240e616c5f Update to pango-1.50.13.
4bd5e5987f Update to sudo-1.9.13p2.

comment:5 by Bruce Dubbs, 9 months ago

Milestone: 11.412.0

Milestone renamed

Note: See TracTickets for help on using tickets.