| Summary: | app-text/groonga: privilege escalation via PID file manipulation | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Michael Orlitzky <mjo> | ||||||
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||
| Status: | IN_PROGRESS --- | ||||||||
| Severity: | trivial | CC: | ajak, kfm, maintainer-needed | ||||||
| Priority: | Normal | ||||||||
| Version: | unspecified | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | ~3 [ebuild] | ||||||||
| Package list: | Runtime testing required: | --- | |||||||
| Attachments: |
|
||||||||
Created attachment 494078 [details]
groonga.confd-r1
@mjo thank you for all your work hunting PID files. @Maintainer please let us know when tree is clean from vulnerable versions Gentoo Security Padawan ChrisADR Maintainer: Ping. |
Created attachment 494076 [details] groonga.initd-r1 The init script for groonga gives ownership of the PID file directory to $GROONGA_USER: start_pre() { checkpath -d /run/groonga -o ${GROONGA_USER:-groonga}... This can be exploited by the $GROONGA_USER to kill root processes, because when you stop the service, root sends a SIGTERM to the contents of that PID file. Since the groonga daemon is not able to drop privileges itself, there is no safe way to use its PID file while running as a non-root user. I'm attaching another version of the init script that takes care of the problem by running groonga in the foreground and letting OpenRC background it (and manage the PID file). I've removed the GROONGA_PID setting from the conf.d file entirely: 1. Nobody cares where it goes, 2. Changing it didn't work anyway (a path is hard-coded in that line above). You might also consider doing the database creation in pkg_config() in the ebuild rather than in start_pre(), but that's unrelated and up to you.