Is the DOAS in AUR insecure?

laichiaheng · 2021-01-31 15:28:01

The official Arch repository has an opendoas package which is developed by Duncaen, the other one in AUR which is named doas is developed by slicer69.
I asked Duncaen about the difference between the opendoas and doas, he said that the other one added new features like vidoas which were implemented in a insecure way, there have also been a number of pretty beginner level security issues which were addressed in commits with misleading titles and downplaying the severity.

https://github.com/slicer69/doas/commit … c840f6af58
https://github.com/slicer69/doas/commit … 65a1e06531

https://xn--1xa.duncano.de/slicer69-doas.html

Does it mean that it isn't secure? Isn't the AUR one from openBSD?

eschwartz · 2021-01-31 15:46:49

Both duncaen's "opendoas" and slicer69's "doas" are PORTS of openBSD, neither one is FROM openBSD.

laichiaheng · 2021-01-31 15:54:45

eschwartz wrote:

Both duncaen's "opendoas" and slicer69's "doas" are PORTS of openBSD, neither one is FROM openBSD.

So they just implement it in a different way? Why does Arch choose opendoas? Is it because that it is more secure?

Head_on_a_Stick · 2021-01-31 16:26:22

slicer69's version is old (based on OpenBSD 6.3) but Duncaen's version is up to date in respect of upstream development and they responded to CVE-2019-25016 *very* quickly indeed so that looks to be the "better" package.

FWIW my Alpine Linux system also uses Duncaen's version.

laichiaheng · 2021-01-31 16:54:05

Head_on_a_Stick wrote:

slicer69's version is old (based on OpenBSD 6.3) but Duncaen's version is up to date in respect of upstream development and they responded to CVE-2019-25016 *very* quickly indeed so that looks to be the "better" package.
FWIW my Alpine Linux system also uses Duncaen's version.

I asked slicer69 on reddit about Duncaen's statement, here is how he replied.

Not even a little. The author misunderstood a configuration setting and assumed doas would allow anyone to run a command as the root user. This was incorrect.
What would happen is, on Linux only in the early days of the porting effort, the username-to-UID translation could return the wrong UID, typically 0 - for the root user. If the user had been granted permissions to run commands in the doas.conf file as the target user they would be granted access, if not then the request would fail as it should.
The author of those complaints allowed his user to run commands as root in the config file, then "tricked" doas into interpreting an invalid username as UID 0. Since his config file allowed him to run commands as UID 0 it worked. He then assumed that meant doas would allow anyone to run commands as root (it doesn't, he had to explicitly allow this access in his config file). If his user hadn't been explicitly allowed to run commands as root in the config file it would have blocked access.
The author then started spreading misinformation about doas claiming it granted everyone root access and saying it was insecure. After the situation was explained to him (and the UID translation layer on Linux made more robust to avoid similar issues) he claimed the issue was "covered up" and started harassing myself and another developer on GitHub and Twitter. We eventually had to block him he was getting so nasty and refused to believe he'd just misunderstood the issue.
He's been trying to convince people ever since on GitHub, and Reddit that doas is insecure, which is sort of ironic since he didn't understand the UID translation issue to begin with.
As for vidoas being implemented in an insecure way, that is sort of silly. All vidoas does is copy the doas.conf file to another location, allow the admin to edit it, confirms the syntax is correct, then copy it back with 0600 permissions. It's just a helper script to automate editing the doas.conf file. There isn't really anything specifically secure or insecure about it, it's just a convenience for people who don't want to run this manually every time they make an edit: "cp doas.conf doas.conf.new ; vi doas.conf.new ; docas -C doas.conf.new; cp doas.conf.new doas.conf".

I'm so confused. Who is right? Who is wrong?

Last edited by laichiaheng (2021-01-31 16:57:15)

V1del · 2021-01-31 17:09:15

Well at some point you have to make up your mind and trust someone. Why are you even asking this question? Are you trying to get away from sudo because of the recent vulnerability? As shown above, both "replacements" had their own cases of security issues in one form or the other, at the end of the day all of this is still software written by humans and humans make mistakes. You aren't going to get away from bugs by running between different implementations, they all have their own implementation quirks and likely eventually their own bugs for what they do intend to do.

Head_on_a_Stick · 2021-01-31 17:21:46

For comparison doas has about 500 SLOC whereas sudo runs at ~60,000 SLOC so I would say that doas is preferable in respect of potential vulnerabilities.

laichiaheng wrote:

Who is right? Who is wrong?

I'm not qualified to comment on that but as I said the slicer69 version is based on a now unsupported OpenBSD release so I do think Duncaen's version should be preferred for that reason alone.

eschwartz · 2021-01-31 17:38:48

Sounds like you've already made up your mind. I'll note, however, that:

I know duncaen somewhat better than slicer69, and trust him
opendoas is far more widely used
the fact that commit messages for security-relevant changes are hidden in commit message titles like "Updated license file." is undeniable proof of a malicious approach to refusing to acknowledge problems
your reddit conversation??? resulted in a response that "Broken UID parsing falls back to root" is invalid, but doesn't assert that "Buffer overflow (privilege escalation to root)" is invalid; this not-disputed security bug was likewise hidden behind a lying commit message.

The response about vidoas is nonsensical and either foolishly or maliciously uses illogic to claim that there is no issue. I have/had no idea whether vidoas is implemented insecurely, but you cannot answer that it is implemented securely "because it just automates the work of doing X Y Z".

From taking a quick look at the script https://github.com/slicer69/doas/blob/master/vidoas, it doesn't look particularly insecure...

Oh wait: https://github.com/slicer69/doas/blob/0 … 0d1/vidoas

This is *literally* the textbook way to write an insecure program. Downright repulsive from someone purporting to write security software.

It was made infinitely more secure by an external contribution a couple months later: https://github.com/slicer69/doas/commit … f0b78a295d

I would consider this as proof positive, that slicer69 is a menace to security.

Implement an incredibly dangerous, horrifically broken script
Get rightfully criticized
Accept external contributions to make it not horrifically dangerous
Respond to criticism by claiming there is no security problem, not because "it was fixed", but because "it's just a convenience for people who don't want to run cp, therefore ipso facto it cannot be doing anything insecure to begin with"

I'm sorry, but if someone wants to distribute security software, their attitude toward "the very basic basics of secure programming" cannot be "if I release code someone will submit a pull request to make it safe".

Last edited by eschwartz (2021-01-31 17:40:54)

duncan · 2021-01-31 19:34:37

Just replying to some accusations made in the quoted post.

The author then started spreading misinformation about doas claiming it granted everyone root access and saying it was insecure.

Yes I do that, but its not really misinformation if I back up those claims with the commits.

After the situation was explained to him (and the UID translation layer on Linux made more robust to avoid similar issues) he claimed the issue was "covered up" and started harassing myself and another developer on GitHub and Twitter. We eventually had to block him he was getting so nasty and refused to believe he'd just misunderstood the issue.

Here are the two comments that were deleted in the PR (https://github.com/slicer69/doas/pull/23) where I fixed CVE-2019-15901 for them:
https://i.imgur.com/gopUSlE.png

And here is the single tweet pointing out an issue with the fix for the uid/gid parsing issue I reported in the deleted comments https://twitter.com/duncaen/status/1168951877603643399 after that they blocked me.

Last edited by duncan (2021-01-31 19:54:45)

seth · 2021-01-31 23:25:21

https://github.com/slicer69/doas/pull/2 … -527467382

slicer69 wrote:

One being that I'm not sure this qualifies as a security concern. Having the group of the calling user is arguably expected, or at least certainly useful. However, I can see why, in some cases it would also be dangerous.

This is at best a "questionable" way to deal w/ problem and at worst dumb (I put "questionable" in quotes because it's actually not…)

I'm not sure this qualifies as a security concern […] However, I can see why, in some cases it would also be dangerous.

is an obvious self-contradiction and in any event: if a system process/script wants to drop privileges to run a service as joeuser, the idea is typically not that joeuser now controls a process that runs as GID0 and, I guess, hope that nothing is root:root/660 so that this can not be used as a privilege escalation?
It seems rather driven by the perspective that doas will only ever be used to elevate privileges from joeuser to UID0…

Also, rule of thumb: eve·ry·thing about a tool for privilege elevation is a security concern.

---

On the upside, randomly grouped shopping list commits seem to be their style…
https://github.com/slicer69/doas/commit … 65a1e06531

Added optimization to Makefile wrote:

- Milk
- Eggs
- Kill my neighbour
- Bread
- Cerials
- Cheese

---

slicer69 wrote:

The author misunderstood a configuration setting and assumed doas would allow anyone to run a command as the root user. This was incorrect.
What would happen is, on Linux only in the early days of the porting effort, the username-to-UID translation could return the wrong UID, typically 0 - for the root user. If the user had been granted permissions to run commands in the doas.conf file as the target user they would be granted access, if not then the request would fail as it should.
The author of those complaints allowed his user to run commands as root in the config file, then "tricked" doas into interpreting an invalid username as UID 0. Since his config file allowed him to run commands as UID 0 it worked. He then assumed that meant doas would allow anyone to run commands as root (it doesn't, he had to explicitly allow this access in his config file). If his user hadn't been explicitly allowed to run commands as root in the config file it would have blocked access.

Woah, wait a second… is this supposed to be a rendition of https://github.com/slicer69/doas/commit … 65a1e06531 ?
Cause that'd be complete bullshit. The patch addresses a pre-processor fuckup that leads to undefined behavior and allowed to interpret random garbage as UID0.
In the very most benign case that gets you in trouble w/ a human error (you typo janeuser as jainuser and end up running as root instead) and even iffff worse was caught down the codepath, that's still just a disaster in the waiting.

Also, seriously, writing this doesn't give them pause?

"tricked" doas into interpreting an invalid username as UID 0

Yeah… so just another wednesday, I guess.
https://sayingimages.com/wp-content/upl … e-meme.jpg

---

I know nothing about those tools beyond this thread and I don't think that yeatanothersudo is a sane way to address all the sudo issues (even if it's far less code than sudo, it's just more code because in reality users will have/require both tools) but what I've seen here is enough to make clear that the github.com/slicer69/doas development has issues with the code quality and, what's much worse, the attitude towards dealing with issues. Enough to stay away from it until this has provenly changed.

Edit: escalator/elevator

Last edited by seth (2021-01-31 23:27:18)

eschwartz · 2021-01-31 23:33:25

seth wrote:

On the upside, randomly grouped shopping list commits seem to be their style…
https://github.com/slicer69/doas/commit … 65a1e06531
Added optimization to Makefile wrote:
- Milk
- Eggs
- Kill my neighbour
- Bread
- Cerials
- Cheese

It's not exclusively the style there, though! I noticed that only some commits were like that, and they tended to be the ones with security vulnerabilities. The impression I got was "shopping list commits are for when you need to hide the vulnerability".

latalante1 · 2021-02-01 00:01:57

I have no such dilemmas.
For me, Archlinux works without the possibility of elevating privileges.

/etc/systemd/system.conf
[Manager]
NoNewPrivileges=yes

Yes, this is quite radical because apart from sudo, su not working, it means that the other setuid binaries and filesystem capabilities will lose their special permissions.

I'm doing fine.

laichiaheng · 2021-02-01 00:32:12

It seems like Duncaen is the VOID Linux maintainer, I think I should trust him more.
I don't read the codes.

Last edited by laichiaheng (2021-02-01 00:32:37)

Arch Linux

#1 2021-01-31 15:28:01

Is the DOAS in AUR insecure?

#2 2021-01-31 15:46:49

Re: Is the DOAS in AUR insecure?

#3 2021-01-31 15:54:45

Re: Is the DOAS in AUR insecure?

#4 2021-01-31 16:26:22

Re: Is the DOAS in AUR insecure?

#5 2021-01-31 16:54:05

Re: Is the DOAS in AUR insecure?

#6 2021-01-31 17:09:15

Re: Is the DOAS in AUR insecure?

#7 2021-01-31 17:21:46

Re: Is the DOAS in AUR insecure?

#8 2021-01-31 17:38:48

Re: Is the DOAS in AUR insecure?

#9 2021-01-31 19:34:37

Re: Is the DOAS in AUR insecure?

#10 2021-01-31 23:25:21

Re: Is the DOAS in AUR insecure?

#11 2021-01-31 23:33:25

Re: Is the DOAS in AUR insecure?

#12 2021-02-01 00:01:57

Re: Is the DOAS in AUR insecure?

#13 2021-02-01 00:32:12

Re: Is the DOAS in AUR insecure?

Board footer