Bug 688698 (CVE-2011-1159)
| Summary: | CVE-2011-1159 acpid: blocked writes can lead to acpid daemon hang | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Vincent Danen <vdanen> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | aglotov, maurizio.antillon, ted |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | acpid 2.0.9 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-06-10 10:57:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 701340 | ||
| Bug Blocks: | |||
I've filed a bug for this because it has a CVE assigned, but I don't understand the problem. If the problem is that acpid hangs if there are no unprivileged processes listening (as described) to the socket to keep the queue empty, then acpid would hang a lot. Using lsof, I don't see anything but acpid opening /var/run/acpid.socket: # lsof -U|grep acpi acpid 1489 root 3u unix 0xffff880137479a00 0t0 10297 socket acpid 1489 root 8u unix 0xffff880137479d40 0t0 10300 /var/run/acpid.socket acpid 1489 root 9u unix 0xffff8800bd6f5a00 0t0 138801 /var/run/acpid.socket There is an exploit attached to the original report to demonstrate it, but by the sounds of things it requires 6-10hrs to trigger (on a laptop). I'll give this a try with my Fedora 14-based laptop, but am I missing something here? If the problem is as described, shouldn't acpid be hanging all the time, or is there something unprivileged that periodically polls the file? Ran the reproducer on my laptop, and it indeed stops counting when it hits 209 messages in the queue. But acpid remains at 0% CPU usage. I'm not sure what messages these are because acpi_listen isn't printing anything. It's possible that acpid has "hung" and isn't writing anything to the socket until the backlog is cleared, but there is no extra CPU or memory usage as a result. If I stop and restart acpid, while this reproducer is running, the count jumps way up and it's receiving way more than 209 messages (currently at 2,000,000 and counting). But acpid is still at 0% CPU and 0% memory. I honestly don't see what the problem here is. Perhaps Jiri or someone else has some idea? I'm also not sure what the reproducer is supposed to do other than tell you how many messages are in the queue. Interestingly, nothing appears to me when running acpi_listen unprivileged until I also use it as root. Once I do that, then the unprivileged acpi_listen starts to print acpi events. When I quit the privileged acpi_listen, I still see new events on the unprivileged one. The counter shown by the reproducer also doesn't reset (after unplugging and re-plugging in the power adapter, with a restarted acpid, I have been sitting at 36 messages in the queue, despite acpi_listen also listening (unprivileged). Unless someone knows something, or can spot something, that I can't see, I would say this is a non-issue. I'll keep this running for a bit to see if anything interesting happens later on perhaps. I was able to reproduce a similar situation by writing a test program to simulate acpid, then connecting to it with the exploit. So I believe the issue is valid. Regardless, the suggested fix is harmless and makes sense. I've made the fix in acpid 2.0.9 which can be found here: http://tedfelix.com/linux/acpid-netlink.html Thanks for that information, Ted. We'll set this aside for something more urgent and fix it in the future (I don't believe this is severe enough to warrant an update on its own). The feedback is appreciated. Created acpid tracking bugs for this issue Affects: fedora-all [bug 701340] |
It was reported [1] that acpid opened the UNIX socket that informs unprivileged processes about acpi evens in blocking mode. If an unprivileged process were to stop reading data from the socket, then after some time the socket queue fills up which would then lead to a hang of the privileged acpid daemon. The daemon will hang until the socket peer process read some portion of the queued data or the peer process exits or is killed. The reporter's solution is to open the socket in non-blocking mode: --- a/acpid.c +++ b/acpid.c @@ -307,6 +307,7 @@ non_root_clients++; } fcntl(cli_fd, F_SETFD, FD_CLOEXEC); + fcntl(cli_fd, F_SETFL, O_NONBLOCK); snprintf(buf, sizeof(buf)-1, "%d[%d:%d]", creds.pid, creds.uid, creds.gid); acpid_add_client(cli_fd, buf); I can't tell if this was reported upstream or not; there are no recent bugs in the SourceForge bug tracker [2]. [1] http://www.openwall.com/lists/oss-security/2011/01/19/4 [2] http://sourceforge.net/tracker/?group_id=33140&atid=407341