Bug 687 - sudo: tgetpass doesn't restore SIGPIPE's action
sudo: tgetpass doesn't restore SIGPIPE's action
Status: RESOLVED FIXED
Product: Sudo
Classification: Unclassified
Component: Sudo
1.8.12
All All
: low high
Assigned To: Todd C. Miller
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-02 02:07 MST by mancha
Modified: 2015-03-21 19:17 MDT (History)
0 users

See Also:


Attachments
patch: properly restore SIGPIPE's action (655 bytes, application/octet-stream)
2015-03-02 02:07 MST, mancha
Details
patch: properly restore SIGPIPE's action (655 bytes, patch)
2015-03-02 02:11 MST, mancha
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mancha 2015-03-02 02:07:45 MST
Created attachment 444 [details]
patch: properly restore SIGPIPE's action

Hello. Slackware 14.1 recently bumped its sudo version from 1.8.6p8 to 1.8.12 to address CVE-2014-9680.

After the upgrade, gaining root via 'sudo -i' and running makewhatis causes gzip (called by makewhatis) to throw a bunch of EPIPEs (see original report: https://tinyurl.com/mmmdrcx).

Gzip was not receiving SIGPIPE and after some digging I discovered the source of the problem is a long-standing bug in sudo's tgetpass: SIGPIPE's signal action is not properly restored.

Sudo 1.8.6p8 also has the bug but in that version a more liberal restore_signals restores the action before exec.

Attached patch against HEAD@20150301 fixes the bug.

To repro, run this script after switching to root with "sudo -i" (make sure to traverse the password-getting code):

-----------------
#!/bin/bash
trap "{ echo Success ; exit 0; }" SIGPIPE
kill -s PIPE "$$"
echo "Failure"
exit 1
-----------------

--mancha
Comment 1 mancha 2015-03-02 02:11:35 MST
Created attachment 445 [details]
patch: properly restore SIGPIPE's action
Comment 2 Todd C. Miller 2015-03-02 08:49:30 MST
Committed, thanks.
Comment 3 Todd C. Miller 2015-03-21 19:16:21 MDT
Fixed in sudo 1.8.13, available now.