New issue
Advanced search Search tips

Issue 846262 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: May 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Security



Sign in to add a comment

Security: Qualys procps audit

Project Member Reported by mnissler@chromium.org, May 24 2018

Issue description

See http://www.openwall.com/lists/oss-security/2018/05/17/1

TL;DR: Qualys didn't an audit of procps, finding some interesting bugs. The privilege escalation CVE-2018-1124 is probably the most interesting one for us. It's somewhat difficult to exploit though.

We should just upgrade to procps 3.3.15 which has fixes for everything we care about. Gentoo already has a fixed ebuild which I will pull in: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-process/procps/procps-3.3.15-r1.ebuild

Setting Severity-Medium, since there isn't a confirmed remote attack vector and the privilege escalation is hard to exploit.
 
Project Member

Comment 2 by sheriffbot@chromium.org, May 24 2018

Labels: M-67
Project Member

Comment 3 by sheriffbot@chromium.org, May 24 2018

Labels: Pri-1
Project Member

Comment 4 by bugdroid1@chromium.org, May 30 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/2bc778addba9057817fa8c7ebd79848f5cd8388a

commit 2bc778addba9057817fa8c7ebd79848f5cd8388a
Author: Mattias Nissler <mnissler@chromium.org>
Date: Wed May 30 00:15:21 2018

security_ASLR: Stop using ps' -C flag in favor of pidof invocation

ps grabs the command name from /proc/${pid}/{comm,stat,status}, backed
by the task struct's comm buffer maintained in the kernel. This buffer
has been limited to 16 characters for a long time, but has been
enlarged recently.

Newer procps versions have followed suit and enlarged their buffers,
however in a backwards-incompatible way: If a new procps is running
against an old kernel, it'll receive only 16 bytes worth of comm.
Commands that overflow the comm buffer thus no longer match the larger
strings user space may compare against, e.g. somewhatlongercmd would
be returned by an old kernel as "somewhatlongercm", but ps -C
somewhatlongercmd wouldn't see it since comparison differs at the
final 'd' character, which the larger userspace buffer will now
detect.

Furthermore, note that the -C flag to ps has always been fragile since
ps would consider every process with a matching comm buffer a match,
but this only takes into account the 16 (now 64) character prefix of
the actual command (i.e. ps -C "somewhatlongercmd123" would have
matched "somewhatlongercmd" processes as well).

Given all this, switch the code to avoid ps' -C flag in favor of a
separate pidof invocation. pidof will consult /proc/${pid}/cmdline
instead, which hopefully will provide more robust results.

BUG= chromium:846262 
TEST=Builds and passes tests.

Change-Id: I5c361b5659b1f2128138af6f6aa9d5fb2bb7a9d6
Reviewed-on: https://chromium-review.googlesource.com/1075187
Commit-Ready: Mattias Nissler <mnissler@chromium.org>
Tested-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>

[modify] https://crrev.com/2bc778addba9057817fa8c7ebd79848f5cd8388a/client/site_tests/security_ASLR/security_ASLR.py

Project Member

Comment 5 by bugdroid1@chromium.org, May 30 2018

Status: Fixed (was: Started)
Project Member

Comment 7 by sheriffbot@chromium.org, May 31 2018

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Project Member

Comment 8 by sheriffbot@chromium.org, Sep 6

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment