[HN Gopher] Heap-based buffer overflow in Sudo
___________________________________________________________________
Heap-based buffer overflow in Sudo
Author : ptype
Score : 88 points
Date : 2021-01-26 18:12 UTC (4 hours ago)
(HTM) web link (www.qualys.com)
(TXT) w3m dump (www.qualys.com)
| jart wrote:
| Developers: your moment has come at last to humble your local
| system administrator for wearing those "I read your emails"
| t-shirts. This is as day zero as day zero gets. Red Hat and
| Debian published their security announcements just two hours ago
| at the exact same moment this was posted on Hacker News. It would
| have been more responsible to keep something this bad under wraps
| a bit longer. Because all the people who still use things like
| cpanel virtual hosting are at risk.
| jeffbee wrote:
| All you need to know about sudo and frankly most other pieces of
| the Linux userspace is that it is undertested. The commit that
| added this flaw to sudo claims to fix a parser bug but includes
| no tests. There is no reason for the author, the reviewer (if
| there even was such a person), or anyone else to believe that the
| bug existed or was fixed by this change. The pull request that
| supposedly fixes this CVE also includes no tests. There is _no_
| reason anyone should believe this fix is effective or complete,
| or that it does not introduce new defects. This is the result of
| people who stubbornly refuse to practice even the most basic good
| engineering practices, like testing and code review, while at the
| same time using the industry 's most dangerous high-level
| language. As long as this type of thing continues, our tools will
| remain at a very low level of safety, reliability, and
| correctness.
| nsajko wrote:
| I think the design of the relevant code is worse than the lack
| of relevant test coverage. The problem solved insecurely by the
| code instead seems like an obvious target for lexical and
| syntactic analysis (and this has been so since the sixties, I
| think).
| miohtama wrote:
| Another question is who wants to maintain four decades old GNU
| C soup? It was written at a different time, with different best
| practices.
|
| In some point someone will rewrite all GNU/UNIX user land in
| modern Rust or similar and save the day. Until this happens
| these kind of incidents will happen yearly.
| jeffbee wrote:
| The GNU project is wall-to-wall toxic waste, but I note for
| the record that I don't think sudo is a GNU program and IIRC
| it's not even GPL.
| umvi wrote:
| > It was written at a different time, with different best
| practices.
|
| Not that I have any faith in modern "best practices". I'm
| imagining `grep` written in modern a modern language like JS
| and I shutter when I think of the hundreds of micro-
| dependencies like "left-pad" that would need to be downloaded
| to make it work.
|
| Maybe it's fair to say that systems programming languages are
| in a better state in terms of modern best practices than
| scripting languages.
| muricula wrote:
| Even if there were basic unit & regression tests, this bug
| might not have been caught. This bug should have gone through
| detailed security review and should probably also undergo
| fuzzing.
| [deleted]
| bpiche wrote:
| Please let this be a reference to Count Zero and the loa of the
| matrix :(
| 2bitencryption wrote:
| I'm curious, is this one implementation of sudo really used
| everywhere?
|
| I was under the impression that different Linux userspaces
| sometimes implement these common commands differently. Like "ls"
| sometimes actually being aliased to a bash script, or maybe BSD
| having one implementation and Ubuntu another. Is that not the
| case? Is "sudo" not maintained by an entity like gnu, bsd, etc?
|
| edit - in other words, I always assumed "sudo" was a highly-
| dependent system-level tool, not just some useful helper binary
| that is maintained by one independent person.
| sigio wrote:
| Nope... sudo is just this sudo in 99.99% of the cases. There
| are some alternatives, such as *bsd's doas, and others, but all
| but doas and su are so non-popular and outdated that I would
| not recommend using them, as they probably have way more
| security issues.
| acct776 wrote:
| doas has a much smaller attack surface, and is worth checking
| out.
| wahern wrote:
| doas is just OpenBSD. You can install doas from ports on
| NetBSD or FreeBSD, just like you can install doas on Linux.
|
| OpenBSD dropped sudo from the base OS several years ago. sudo
| just became too complex, tailored to the feature creep
| demanded and required (PAM, _ugh_ ) by Linux users.
| turminal wrote:
| Briefly going through their website (sudo.ws) I am
| seriously wondering why anyone would want to put some of
| those features in a privilege management tool.
| wahern wrote:
| Todd Miller is a sharp developer and core OpenBSD
| contributor. I can only imagine the deluge of requests
| and pressure he faces to expand sudo. There's no end to
| the crazy stuff corporations demand, especially when it
| comes to integration--audit, logging, ldap, etc.
| TheDong wrote:
| > Like "ls" sometimes actually being aliased to a bash script,
| or maybe BSD having one implementation and Ubuntu another
|
| It is true that BSD and linux sometimes have different
| implementations of posix commands.
|
| The vast majority of linux distros are using the same gnu
| coreutils though. There are alternate implementations (like
| busybox, among others), but they're not often used in desktop
| distros.
|
| I'm curious if you have any example of a linux distro that does
| treat ls so weirdly; that uses anything other gnu coreutils or
| busybox for it.
| bawolff wrote:
| Wikipedia has a history section
| https://en.wikipedia.org/wiki/Sudo#History
|
| But every tool has to be maintained by someone. Its not like
| GNU is a faceless corporation.
| MayeulC wrote:
| Memory safety strikes again, it seems (overflow in a C string due
| to complex parameter parsing rules).
| ddevault wrote:
| No, complexity strikes again. I haven't used sudo in years,
| preferring to use doas now. Its essential code is less than 500
| lines and it does everything I've ever used sudo for, and that
| includes much more than `sudo <runupdates>`.
| $ man doas | wc -l 58 $ man doas.conf | wc -l
| 101 $ man sudo | wc -l 741 $ man
| sudoers | wc -l 3254
|
| And a bonus: $ man sudoers | grep -C1 despair
| The sudoers file grammar will be described below in Extended
| Backus-Naur Form (EBNF). Don't despair if you are
| unfamiliar with EBNF; it is fairly simple, and the
| definitions below are annotated.
|
| That only accounts for a small subset of sudo's complexity.
| It's easily 100x more complex than it needs to be to solve this
| problem. Now compare the two CVE lists:
|
| http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/security/doa...
|
| http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/security/sud...
|
| My reaction to this vulnerability was mild amusement, then
| later wondering if I should go discredit the inevitable Rust
| brigade. We don't have to rewrite everything in Rust to get
| better security. We just have to use simpler tools.
| comex wrote:
| But if sudo were written in Rust, it could have the same
| level of complexity and not be vulnerable.
|
| Yes, it would still be vulnerable to logic errors, like the
| _last_ famous sudo bug where you pass -1 as the UID. But it
| wouldn 't be vulnerable to this. (And this isn't the first
| memory safety bug to be found in sudo.)
|
| Yes, sudo's complexity is useless for 99.99% of its users.
| But wouldn't it be nice if the result were merely a gross
| feeling rather than a security hole?
| ddevault wrote:
| >But if sudo were written in Rust, it could have the same
| level of complexity and not be vulnerable.
|
| This is not true. Complexity breeds bugs, including
| security bugs, and memory safety doesn't change that. Your
| example is a good one - here's another: doas once failed to
| limit the environment variables which are passed to the
| child process, which could be used to nefariously influence
| the program running (e.g. with LD_PRELOAD). How would Rust
| prevent that oversight? It wouldn't.
|
| A simpler program will generally be more secure than a
| complicated one, no matter what language either is written
| in. Furthermore, _rewriting_ an established program from
| one language to another will _always_ introduce more bugs
| than it fixes, and more severely the more complex the
| program is. The single best way to improve security is to
| reduce the attack surface, and the single best way to do
| that is to reduce the complexity of your system.
| zamadatix wrote:
| If you go a little further with the quote:
|
| "Yes, it would still be vulnerable to logic errors... But
| it wouldn't be vulnerable to this. "
|
| I think you'll find in disagreeing with the comment on
| logic errors you just said the same thing the comment did
| about logic errors.
|
| Also I think the generalization that rewriting an
| established bit of code in a new language in a secure
| language is a bit too general. clearly Firefox not only
| set out to make Rust for this purpose but it's not had an
| explosion in vulnerabilities with the modules it has
| replaced. Quite the opposite actually. Nor has every tool
| or app rewritten become a security failure compared to
| the original. I do think it's something that can easily
| be screwed up though, especially if someone rushes
| through by focusing on functionality duplication instead
| of building a more secure version of something.
|
| Regardless, both "using a memory safe language results in
| a more safe program" and "having a minimum attack sufrace
| results in a more safe program" can be true. There is no
| need to make it a choice of A or B.
| ddevault wrote:
| >I think you'll find in disagreeing with the comment on
| logic errors you just said the same thing the comment did
| about logic errors.
|
| I think you'll find that my comment explicitly
| acknowledges this and expands on it with another example.
| Are we done telling each other to read the things we're
| writing?
|
| >Firefox not only set out to make Rust for this purpose
| but it's not had an explosion in vulnerabilities with the
| modules it has replaced.
|
| You're setting the bar pretty high with an "explosion" of
| vulnerabilities here. Rust programs have vulnerabilities,
| including rewrites. They also have other kinds of bugs,
| often ones which were not present in the code that
| they're replacing. You need only browse your nearest
| convenient RiiR bug tracker to find evidence of this.
|
| Let me restate my thesis in mathematical terms. If we
| presume that 1 in 100 lines of production code has a bug
| in it, regardless of language (generous, I know), and
| that 1 in 10 bugs in C programs are memory corruption
| related, then saving 10% of those bugs by rewriting it in
| Rust would take a 10,000 line codebase from 100 bugs to
| 90 bugs. A 1,000 line codebase, still written in C and
| without the advantage of memory safety, would have only
| 10.
|
| In today's example, sudo is a caricature of runaway
| complexity. Rust is often touted as a panacea, but C has
| very little to do with why sudo is insecure. Sudo is
| comically overengineered and that level of
| overengineering has no place in a security context. This
| is the larger issue that needs to be addressed, not Rust.
| arp242 wrote:
| > We don't have to rewrite everything in Rust to get better
| security. We just have to use simpler tools.
|
| People don't add these features for the fun of it; they're
| present because they solve a specific use case.
|
| I use doas as well; it's a neat little program that covers
| many of the _common_ use cases, but it doesn 't cover _all_
| of them. Usually you should use the simplest tool that solves
| your problem, but sometimes your problem is complex and thus
| your tool will be complex.
|
| That is not to say that sudo can't perhaps be simpler; the
| first version was released in 1985 and there are probably
| things that can be improved, but sudo really isn't written by
| idiots who just add features because they have nothing better
| to do.
| ddevault wrote:
| Adding features because they solve a specific use-case is
| grossly irresponsible. Solving a specific use-case is only
| one of many criteria that needs to be met for a feature to
| be justified. Others include "is it in scope?", "is it a
| maintenance burden?", "does it make existing features more
| unreliable?", "will its bugs affect people who don't need
| it?", "can it be done in a separate tool?" Anyone can come
| up with a use-case. It's often the maintainer's job to say
| "no".
|
| If doas doesn't cover your edge case, then the responsible
| thing is to make a new tool which covers just that, and not
| to shove your complexity into a critical security component
| that the other 99% of the userbase doesn't need. Remember
| Heartbleed? The entire internet shat its pants because of a
| vulnerability in a feature that no one uses.
|
| Failing to uphold that principle over and over again leads
| to broken, unreliable, insecure programs. This is why
| everything is on fire. Not C.
| mulmen wrote:
| Fair point re: complexity but how are CVEs in one codebase
| evidence of absence of bugs in another?
|
| Or said another way, is the lack of CVEs for doas an
| indication it is more secure or just less (ab?)used?
| ddevault wrote:
| More CVEs can also sometimes be a function of exposure; Joe
| Random's program probably has no CVEs but that doesn't mean
| it's more secure than Jane Popular's tool. In this case,
| however, both sudo and doas have sufficient exposure to
| estimate their relative security using CVEs. We can also
| use the CVEs to characterize the kinds of vulnerabilities
| each has internally, without comparing them to each other.
| In general, the CVEs that are discovered for sudo are more
| severe and damning than those discovered for doas, without
| respect to their relative occurance.
| cjohnson318 wrote:
| Any idea why did they referenced Baron Samedi?
| https://en.wikipedia.org/wiki/Baron_Samedi
| tekstar wrote:
| He shows up in a William Gibson novel, in the Neuromancer
| series.
| prutschman wrote:
| I think it's a pun on the `sudoedit` utility used in one of the
| exploit paths.
| jzer0cool wrote:
| Any list somewhere which provides a list of affected OSs or at
| least how to check?
| wtfishackernews wrote:
| sudo --version
|
| anything below version 1.9.5p2 is affected
| comfydragon wrote:
| Unless the patches have been backported, as is the case for
| Ubuntu 18.04, in which case it may not need to be 1.9.5p2. ht
| tps://launchpad.net/ubuntu/+source/sudo/1.8.21p2-3ubuntu1....
| jzer0cool wrote:
| how to patch (e.g. ubuntu)? or requires compiling from
| source?
|
| EDIT: see above post provided by comfydragon
| thricegr8 wrote:
| Here is a non .txt format with a great video explanation as well:
| https://blog.qualys.com/vulnerabilities-research/2021/01/26/...
| zaltekk wrote:
| > introduced in July 2011 (commit 8255ed69), and affects all
| legacy versions from 1.8.2 to 1.8.31p2 and all stable versions
| from 1.9.0 to 1.9.5p1, in their default configuration.
|
| It looks like this is pretty far reaching. All of my boxes were
| vulnerable to this before updating today.
| krapp wrote:
| In case no one gets the pun:
| https://en.wikipedia.org/wiki/Baron_Samedi
| rkachowski wrote:
| also the very final boss character in goldeneye 007 for n64
| mrlonglong wrote:
| Good memories playing with Voodoo mode on x86.
| zaltekk wrote:
| > introduced in July 2011 (commit 8255ed69), and affects all
| legacy versions from 1.8.2 to 1.8.31p2 and all stable versions
| from 1.9.0 to 1.9.5p1, in their default configuration.
|
| It looks like this is pretty far reaching. All of my boxes were
| vulnerable to this before updating today.
| nickweb wrote:
| Is it normal for a security issue of this magnitude to have a 12
| day notification period for everyone? That seems... short.
| jwilk wrote:
| Yes. This was coordinated on the distros mailing list, which
| has maximum embargo period of 14 days, with periods shorter
| than 7 days preferable:
|
| https://oss-security.openwall.org/wiki/mailing-lists/distros...
| nahuel0x wrote:
| "rewrite sudo in Rust" in 3,2...
| pjmlp wrote:
| Why? After all it is obvious code reviewers are enough to catch
| any typical C memory corruption error.
| eqvinox wrote:
| People use the tools they have available and understand.
| Rust, at the time this bug was introduced into sudo, was
| barely a year old, and hadn't even released 0.1 yet.
|
| Also, the sarcasm in your comment really doesn't help your
| message.
| pjmlp wrote:
| I have been advocating against C since comp.lang.c days, no
| need for lessons about how to market something that the
| audience obviously isn't interested into paying attention.
|
| The first systems programming language that would prevented
| this kind of exploit was written in 1961, 10 years before C
| was invented.
| nahuel0x wrote:
| Note, beyond all sarcasm, I adhere. At least all critical
| pieces like sudo must be rewritten in a safer language
| than C.
| eqvinox wrote:
| Neither of these is an excuse for the condescending,
| snarky tone.
|
| [Ed.: Actually, the tone is probably a factor in the
| audience not being interested.]
|
| [Ed. 2: https://news.ycombinator.com/item?id=21490714 ]
| pjmlp wrote:
| As usual in everything tech related, it depends.
| nsajko wrote:
| Firstly, the constant nagging (of the kind appearing here,
| and often on other HN threads) against C and family are
| obnoxious. Any language will have both downsides and upsides
| and picking this one "flaw" in C and then pretending like
| it's a reason that C absolutely shouldn't be used is absurd.
|
| Secondly, the Sudo code in question seems to be a result of a
| poor or nonexistent design process (which also seems
| consistent with Sudo's horrific bloat of features), so this
| isn't a good example for preaching against C.
|
| Slightly off-topic, but FTR I view C as somewhat crippled and
| C++ as an easy to misuse Lovecraftian monstrosity (but much
| more powerful and useful than C), and I suspect Rust's way of
| forbidding the user from making memory errors is more trouble
| than it's worth.
| jart wrote:
| Or just recompile sudo with -fsanitize=address
| netsec_burn wrote:
| Shouldn't this affect macOS?
| ArchOversight wrote:
| sudoedit doesn't seem to be installed?
| brohee wrote:
| Not the thing saving you, as it is sudo invoked as sudoedit
| that permits entering the bad codepath... A simple symbolic
| link and you now have sudoedit.
|
| And... macOS looks vulnerable to me % cd ~ &&
| ln -s /usr/bin/sudo sudoedit && ./sudoedit -s /
| Password: sudoedit: /: not a regular file
|
| As per the advisory it looks vulnerable (sudoedit: and not
| usage:)
| eqvinox wrote:
| <insert "oh shit" here>
| ncmncm wrote:
| I don't find bug reports for this in either Debian or Ubuntu bug
| tracking systems. When do these get entered?
| ximm wrote:
| https://security-tracker.debian.org/tracker/CVE-2021-3156
| throw0101a wrote:
| Also, if you run a large Debian farm, it may be worth
| subscribing to _debian-security-announce_ :
|
| * https://lists.debian.org/debian-security-announce/
|
| The message for this issue went out 18:05 UTC:
|
| * https://lists.debian.org/debian-security-
| announce/2021/msg00...
|
| See also the RSS feed for:
|
| * https://www.debian.org/security/
| bboozzoo wrote:
| There's a corresponding Ubuntu security notice:
| https://ubuntu.com/security/notices/USN-4705-1
| fattire wrote:
| sudo built with ASLR doesn't make a difference?
|
| NM:
|
| - we can defeat ASLR by partially overwriting the function
| pointer getenv_fn (which points to the function
| sudoers_hook_getenv() in the shared library sudoers.so); and
| luckily, the beginning of sudoers.so contains a call to execve()
| (or execv()):
| [deleted]
| Panino wrote:
| Qualys is great! Love their vulnerability reports.
|
| Just want to echo other praise here for doas. It's fantastic,
| most likely does everything you need it to do, and is secure.
| Install it and see for yourself!
| cab404 wrote:
| Never knew sudo had a site (https://sudo.ws).
|
| Never knew it had a mascot, if you could call it so... I will
| never unsee it. Nightmare fuel at it's finest.
| bitwize wrote:
| Oh my God, it's a reference to the "sudo make me a sandwich"
| XKCD on top of it all.
| rootsudo wrote:
| That's the best, I didn't/couldn't believe it, but it's true.
|
| This made my day. God it is scary.
| BenFeldman1930 wrote:
| Every time you run it, it is eating a part of your soul. _Nom
| nom nom_
| hpcl wrote:
| For years we have been indoctrinated that having a root account
| is evil and sudo is the proper salvation.
|
| Turns out that any user could make a root account.
| megous wrote:
| One of those programs that you should not install unless you
| really need them.
| wahern wrote:
| Not sure if you were being sarcastic, but OpenBSD removed sudo
| several years ago. The native tool is doas:
| https://man.openbsd.org/doas sudo just became too complex, what
| with the feature creep demanded by corporate Linux users.
___________________________________________________________________
(page generated 2021-01-26 23:00 UTC)