5

I'm reviewing the /etc/sudoers file on a machine in response to CVE-2019-18634, a buffer-overflow vulnerability present in sudo. The bulletin on the sudo.ws website recommends the following mitigation:

If the sudoers file has pwfeedback enabled, disabling it by pre-pending an exclamation point is sufficient to prevent exploitation of the bug. For example, change:

Defaults pwfeedback

To:

Defaults !pwfeedback

However, upon reviewing the sudoers file, the configuration I see is what I presume is an implicit deny, where there is no mention at all of pwfeedback, which has sparked my curiosity.

What I've tried so far:

I have tested the behavior of sudo when pwfeedback is explicitly denied by adding Defaults !pwfeedback to the sudoers file as per the recommended mitigation, as well as when there is nothing added. As I would expect, there is no difference in behaviour. This appears to confirm my belief that (in this instance) anything not explicitly allowed is treated as implicitly denied.

My question: Both solutions appear to solve the issue, removing Defaults pwfeedback from the sudoers file should work by itself, I think.

Is explicitly disabling a default in the sudoers file the same as not listing it at all?

Alain O'Dea
  • 1,615
  • 9
  • 13
Joshua Murphy
  • 146
  • 16

1 Answers1

4

Both solutions appear to solve the issue, removing Defaults pwfeedback from the sudoers file should work by itself, I think.

You are correct because, as per the sudoers(5) man page, the implicit default for pwfeedback is off:

pwfeedback' By default, sudo reads the password like most other Unix programs,
by turning off echo until the user hits the return (or enter) key. Some users
become confused by this as it appears to them that sudo has hung at this point.
When pwfeedback is set, sudo will provide visual feedback when the user presses
a key. Note that this does have a security impact as an onlooker may be able to
determine the length of the password being entered. This flag is off by default.

However, when there is an active vulnerability like CVE-2019-18634, mitigation advice is often to explicitly disable, for a few reasons:

  1. An explicit disable is easier to audit than an implicit default disable.
  2. An explicit disable will work even if a particular packager has altered the implicit default.
  3. An explicit disable is more comforting to some people than trusting implicit defaults.
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 1
    Thank you, that's a great answer. So would it be safe to say that while pwfeedback is implicitly denied out of the box with sudo, this is not always the case with other defaults? I'm curious about what another similar vulnerability in the future would look like that could exploit a default enabled implicitly out of the box. – Joshua Murphy Feb 05 '20 at 15:55
  • 2
    @JoshuaMurphy each flag has a default and, unlike some programs, the sudoers man page is very good about telling you what they are. Even then, some are tricky - _compress_io_ is on by default _when sudo is compiled with zlib support_, which will vary by package and distribution. And see _env_editor_ which is on by default and described as a potential security hole. In short, you could easily figure out which options are on by default, and as such more dangerous if found to have a vulnerability. Finding actual vulnerabilities in those options is harder and left as an exercise to the reader. – gowenfawr Feb 05 '20 at 16:04