[SA 2020-002] Security flaws in setuid wrappers, CVE-2020-10936

[ikedas]

Version

Sympa 6.2.54 or earlier.

Installation method

Any.

Expected behavior

There are no flaw.

Actual behavior

Sympa SA 2020-002 (candidate): Setuid wrappers should clear environment variables to avoid exploits.

Additional information

• A security advisory will be published.
• Prepare pull request which will be merged soon.
• New version of Sympa and a patch will be released.

[lightsey]

Just for the record, this vulnerability is (apparently) miscredited and the fix is incomplete. I reported this vulnerability in 2016. Here is the timeline of my interactions with Sympa:

29 Jan 2016 - Contacted sympa-authors and asked where to send security reports

29 Jan 2016 - David Verdin replied that the sympa-authors list was the correct destination for security reports.

29 Jan 2016 - Provided three POC attacks for the setuid wrappers to sympa-authors mailing list and the Debian security team. The first issue I reported was the vulnerability fixed here, the other two issues are still exploitable after this fix.

31 Jan 2016 - Reported an RCE flaw to pair it with to sympa-authors and the Debian security team.

8 Feb 2016 - After getting no response from sympa-authors to any of these messages so I sent a follow up to sympa-authors and the Debian security team to confirm they had received them.

8 Feb 2016 - Salvatore Bonaccorso of the Debian security team responds that they had received my prior emails emails.

9 Feb 2016 - David Verdin from Sympa responded that he had received my emails and would look into it.

9 Feb 2016 - David Verdin responded that the POC attacks on the setuid wrappers were not meaningful because they were local.

9 Feb 2016 - I responded that I had sent 3 local and 1 remote attacks. I explained that local privilege escalation attacks are indeed security issues. I provided an example of a local privilege escalation attack against mailman that was handled as a vulnerability and assigned a CVE.

10 Jun 2018 - I contacted David Verdin, the Sypa authors list, and the Debian security team again to find out what the status of these issues was.

11 Jun 2018 - David Verdun replied that Sympa did plan to fix the issues and that he was forwarding the information to Sympa's security list.

11 Jun 2018 - After checking the code to confirm no fixes had been applied, I emailed a one line local-root POC attack to demonstrate the risk.

12 Jun 2018 - David Verdun replied that he had forwarded this additional POC to Sympa's security list.

26 Aug 2018 - I requested assignment of CVE-2018-1000671 for an open redirect flaw reported by Hanne Moa to Sympa's github bug tracker.

26 Aug 2018 - I emailed David Verdin, the Sympa authors list, and the Debian security team that I would continue waiting for some action from Sympa until the 3 year anniversary of my initial report (Feb 2019), then I would dump the issues in a public bug tracker and be done with it.

7 Sep 2018 - The CVE assignment led to some direct back and forth with Soji Ikeda of the Sympa project. One of my emails asked him to confirm that my message about the unresolved vulnerabilities in Sympa had been received since no reply was sent by any representative of Sympa. Soji responded stating "sympa-authors list is no longer responsible. Please send to sympa-security list where persons in charge (including me) are watching."

16 Sep 2018 - I emailed the sympa-security list details from all of my prior reports, and several additional methods for RCE attacks against default configurations of Sympa. The new RCE methods relied on mistakes in Sympa's security model and mistaken assumptions about the security guarantees of the modules that Sympa uses.

This led to some back and forth where I explained to Sympa that I had already directly spoken to the authors of the modules Sympa uses and the RCE attacks are problems with Sympa's use of these modules rather than problems in the modules directly.

29 Sep 2018 - I sent Ikeda Soji and the Sympa Security list an example patch for one of the setuid wrappers. This patch demonstrated how to fix the environmental variable filtering as done in SA 2020-002. It also demonstrated how to fix the other vulnerabilities in the setuid wrappers that SA-2020-002 does not correct. This patch included detailed comments to explain why each step is required to drop privileges correctly.

There were a few follow up emails after this, arguing that the design flaws I pointed out on 16 Sep 2018 were someone else's problem to fix and me providing additional POC payloads to demonstrate that it was impossible to fix those modules to support Sympa's unsupported use-case.

In Feb 2019 I decided it wasn't worth wasting more of my own time reverifying all of my prior vulnerability reports, dumping them publicly, and dealing with the fallout that releasing unauthenticated remote-root 0-days in Sympa would create.

24 May 2020 - Sympa annouced SA-2020-0002 with a fix for one of the three vulnerabilities in the setuid wrappers I reported originally in 2016 and provided a patch for in 2018. Keeping true to form, Sympa not only left the setuid wrappers with other unresolved vulnerabilities...they credited someone else for finding the one vulnerability that was fixed.

I have attempted in this timeline to avoid mentioning any specific details about unresolved vulnerabilities that could be abused by an attacker, but I'd expect anyone with a reasonable understanding of privilege dropping code can readily identify some of the other mistakes in the current implementation.

[ikedas]

Hi @lightsey ,

Sorry for insufficient response by developers.

Three fixes of this issue may be the same as that you proposed at first, but they have been given up at that time. Because:

• We couldn't realise that this vulnerability can take over root privileges.
  A report at this time described posibility of root exploit by combining two sorts of wrappers. The POC in your report looked, for us, proving exploit of sympa user only.
• Fixing FastCGI wrapper would avoid using it as CGI. Though CGI mode has been stated being deprecated in 2017 (Sympa 6.2.23b.1), it was known that some people continued using CGI mode.
• Exploit can be caused only by local users.

That's why we have given up adopting your report. It's due to our lack of considerations. And I apologize we have not described what we had decided.

---

The other problems you described in your comment would be better to be discussed on the new issue (if it has not been solved). Please feel free to submit it.

[lightsey]

If you reread the emails I've sent to Sympa over all this time, you'll see that I pointed out that setuid wrapper vulnerabilities could be used for local root privilege escalation starting on 11 Jun 2018 when I rechecked my original reports from 2016.

I provided specific shell commands and shell output to demonstrate that. I also CC'd the Debian security team on that email if Sympa's mailing lists no longer have copies of it.

My summary email of all the problems on 16 Sep 2018 was specifically titled "Remote root vulnerabilities in sympa", and the first item on that list was:

1) Environmental variables are not cleared by the sympa setuid
wrappers. This makes it trivial for any local attacker to gain root
privileges.

After this description I provided a shell command to run that gives root privileges.

If you are trying to argue that I didn't cleanly separate distinct vulnerabilities, that I didn't do enough to explain their importance, or that I didn't do enough to follow up on them properly, you are obviously wrong.

It doesn't really matter to me whether or not you admit Sympa's mistakes in handling these vulnerability reports. I'd be very surprised if you did own up to past mistakes.

I don't intend to waste any more of my time following up on the other vulnerabilities further.

I would suggest you reread the patch I sent to the sympa-security list on 29 September 2018. It shows exactly how to fix the remaining flaws in the setuid wrappers.

[Beuc]

@lightsey I'm part of the Debian LTS Team.
If you think CVE-2020-10936 is not completely fixed by 3f8449c , or if there are other vulnerabilities in the suid wrappers, please provide more details here and I can quickly get a new CVE to track it.
(By now distros such as Ubuntu have shipped this fix and consider the issue closed.)

[lightsey]

@Beuc I'm not very inclined to spend even more time on this stuff. If you'd like to go through the full chain of emails that discussed remotely exploitable flaws to combine with the setuid wrapper flaws, send me a signed email from your debian.org address and I'll forward you the full email discussion chain from 2016 and 2018.

I'll attach the patch I sent in 2018 illustrating how to write a reasonably sane setuid wrapper for Perl code. The problems my patch addresses in the newaliases wrapper generally are applicable to the wwsympa-wrapper and sympa_soap_server-wrapper. Those issues are:

1. filtering environmental variables
2. checking return value of setuid()/setgid()
3. switching to a safe starting directory
4. setting a umask rather than relying on an inherited umask to restrict file/directory permissions
5. clearing inherited supplemental groups
6. disconnecting from an inherited TTY
7. setting sensible permissions on the setuid binaries
8. validating the command line arguments

SA 2020-002 fixes only the environmental variable filtering (item 1). That problem is so simple to exploit for local root that I didn't spend time writing full POC attacks for the other bugs.

Item 2 is trivial to exploit with older 2.x linux kernels (likely not as relevant now).

Item 3 is trivial to exploit with older Perl versions that omit the CVE-2016-1238 patch (RedHat 6 & 7 should still be vulnerable).

Item 4 is likely still exploitable in all environments to compromise the sympa account. (set umask 000...run wrapper...modify the world-writable files that are created)

Items 5, 6, 7 and 8 provide attack channels for escalating to root privileges in all environments once the sympa account is compromised.

These are all fairly standard items to take care of in a setuid wrapper around an interpreted script...regardless of the scripting language.

sympa-6.2.36-securewrapper-lightsey.diff.txt

[ikedas]

Hi @lightsey
Thank you for your inputs.

This issue about CVE-2020-10936 and its fixes was closed. If you want to discuss on the other issues, please open the new issue.

[Beuc]

@lightsey thanks for the additional information.
This is a list of standard good practices for setuid programs. However CVEs will only be attributed for effective vulnerabilities.

One possible vulnerability you document in your patch, allowing *->root escalation, is passing an alternate configuration file to sympa_newaliases-wrapper.
However, sympa_newaliases.pl has an old bug, as it uses $main::options{config} which is undefined (unlike $options{config}), so it's not exploitable as it is AFAICS (though this would be better dropped entirely).

A more concrete vulnerability you document in your patch, is that sympa.conf (as well as its entire directory) is owned by user 'sympa', so an attacker who compromised 'sympa' doesn't need to pass an alternate configuration, they can directly edit the main one and escalate to root. This warrants requesting a new CVE, and a new bug report.
Do you want to do that, or should I?

[ikedas]

Hi @Beuc ,

A more concrete vulnerability you document in your patch, is that sympa.conf (as well as its entire directory) is owned by user 'sympa', so an attacker who compromised 'sympa' doesn't need to pass an alternate configuration, they can directly edit the main one and escalate to root. This warrants requesting a new CVE, and a new bug report.
Do you want to do that, or should I?

How "an attacker who compromised 'sympa'" is possible?

[Beuc]

Hi @ikedas

(just to clarify I meant "user 'sympa'")

sympa->root is a demonstrated privilege escalation, abeilt with a lower priority than *->root.
It is nevertheless a vulnerability, and warrants being tracked and fixed.
See https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3689 for a similar vulnerability, although user 'sympa' has a greater exposure (including remote services) than 'statd'.

Incidentally I wouldn't be surprised if a *->sympa escalation is discovered soon, given the information from this thread and the presence of sympa-owned setuid fcgi binaries. On a RHEL environment it looks like it is already possible with item 3.

[ikedas]

Incidentally I wouldn't be surprised if a *->sympa escalation is discovered soon, given the information from this thread and the presence of sympa-owned setuid fcgi binaries. On a RHEL environment it looks like it is already possible with item 3.

I see. However, in fact Sympa relys on privileges of sympa user. I can only understand we have to close flaw that causes unintentional escalation.

[Beuc]

"sympa->root shell" is an unintentional escalation so I think we agree there is a vulnerability to fix here :)

[ikedas]

"sympa->root shell" is an unintentional escalation so I think we agree there is a vulnerability to fix here :)

I see. Could you please report it to sympa security team?

[lightsey]

@lightsey thanks for the additional information.
This is a list of standard good practices for setuid programs. However CVEs will only be attributed for effective vulnerabilities.

You're mixing together the concepts of vulnerabilities and exploits. CVEs have been issued for identical problems in numerous other setuid binaries.

I'm not at all concerned with getting credit for 8 CVEs instead of 1 CVE. It would have saved me substantial amounts of time if the Sympa authors had just accepted that the environmental variables were readily exploitable four years ago and fixed all of the other issues at the same time just to be cautious.

The point I'm trying to make is that the setuid binaries are still vulnerable to attack and the techniques for weaponizing these vulnerabilities into exploits should be readily apparent to anyone that has looked at similar vulnerabilities in other setuid binaries. A few examples: CVE-2005-4890, CVE-2019-12577, CVE-2017-6964, CVE-2018-1386.

I would have happily explained exactly how to write exploits for every one of the problems I reported if there had been any tangible progress from Sympa's side in addressing the issues. I provided Sympa this specific local-root POC exploit code for the environmental variable issue in September 2018...which was essentially ignored and downplayed until someone else reported the exact same problem in 2020:

PERL5OPT='-d' PERL5DB='BEGIN{$0 =~ /newaliases/ ? exec(q{/usr/bin/id}) : exec(q{/usr/lib/sympa/bin/sympa_newaliases-wrapper})}' /usr/lib/cgi-bin/sympa/wwsympa-wrapper.fcgi

One possible vulnerability you document in your patch, allowing *->root escalation, is passing an alternate configuration file to sympa_newaliases-wrapper.
However, sympa_newaliases.pl has an old bug, as it uses $main::options{config} which is undefined (unlike $options{config}), so it's not exploitable as it is AFAICS (though this would be better dropped entirely).

A more concrete vulnerability you document in your patch, is that sympa.conf (as well as its entire directory) is owned by user 'sympa', so an attacker who compromised 'sympa' doesn't need to pass an alternate configuration, they can directly edit the main one and escalate to root. This warrants requesting a new CVE, and a new bug report.
Do you want to do that, or should I?

I have no plans to follow up on this further. If you'd like to do so, send me a GPG signed email from your debian.org address and I'll email you the remote code execution attack details that I also reported to Sympa. RCE attacks are generally more important to an attacker than LPE attacks.

[Beuc]

I created 2 issues for what was discussed and requested 1 CVE for #1009

@lightsey distros don't play a mediator role, we're here to identify fixes for reported vulnerabilities and ensure we provide fixed versions to our users.
Maybe the Sympa devs and you could interact through a 3rd-party such as https://www.hackerone.com/ / https://www.yeswehack.com/ / any trusted 3rd-party enforcing a disclosure policy.

[lightsey]

@lightsey distros don't play a mediator role, we're here to identify fixes for reported vulnerabilities and ensure we provide fixed versions to our users.

Of course, that's completely understandable. If Sympa doesn't want to resolve the issues there are only a few ways to prod them into action.

As I mentioned, I'm reluctant to dump remote-root 0day POC attacks publicly to compel them since doing so will directly harm Sympa's users. I've only included details here that should be very obvious to anyone familiar with setuid binary attacks.

The POC payload for Sympa CVE-2020-10936 in my prior message is an obvious variation of the well known exploit code for Exim CVE-2016-1531. I reported CVE-2016-1531 to Exim around the same time I was trying to convince Sympa to fix their identical vulnerabilities. Exim fixed the issue promptly and fully, Sympa let it linger until 2020 before releasing a half-hearted fix.

I have only posted additional information about the setuid binaries here since Sympa yet again asserted that they are not vulnerabilities and are not worth fixing.

If you (or anyone else from a reputable group that isn't going to sell the exploit code for profit) wants to try and get the remaining issues resolved though, I'm happy to pass along the details I'm aware of. I already provided this information to Sympa's security team.