Issue description

Here is a Chrome OS exploit chain. See writeup.pdf.
1. JS to root
JS goes to root directly by exploiting shill, the Chrome OS network manager. The vulnerability is a one byte overflow in c-ares, the DNS client library used by shill. The bug can be seen in https://github.com/c-ares/c-ares/blob/cares-1_7_5/ares_mkquery.c#L101 :
len = 1;
for (p = name; *p; p++) { // (1)
if (*p == '\\' && *(p + 1) != 0)
p++;
len++;
}
if (*name && *(p - 1) != '.') // (2)
len++;
*buflen = len + HFIXEDSZ + QFIXEDSZ;
*buf = malloc(*buflen);
q = *buf; // (3)
q += HFIXEDSZ;
while (*name) {
len = 0;
for (p = name; *p && *p != '.'; p++) {
if (*p == '\\' && *(p + 1) != 0)
p++;
len++;
}
*q++ = (unsigned char)len; // (4)
for (p = name; *p && *p != '.'; p++) {
if (*p == '\\' && *(p + 1) != 0)
p++;
*q++ = *p;
}
if (!*p)
break;
name = p + 1;
}
*q++ = 0;
// writes QFIXEDSZ bytes at q
DNS_QUESTION_SET_TYPE(q, type);
DNS_QUESTION_SET_CLASS(q, dnsclass);
Briefly, at (3) it parses the dot separated parts of a DNS name and writes them into *buf. A one byte length is also written for each part at (4) and the terminating dot is omitted. The last part may or may not end with a dot. The buffer size is calculated in (1) as basically just the string length. For n length bytes there is either n or n - 1 dots depending on whether the last part ends with a dot. The check at (2) is meant to account for the n - 1 dots case, it adds +1 to buffer size for the length of the last part.
Now, dots can be escaped though and "\." is not considered to be a part terminator. If the last part ends with a "\." then it doesn't have a dot terminator so (1) doesn't account for its length byte. (2) thinks that the last part does end with a dot and doesn't add +1 for the length byte either. The buffer remains too short and overflows by one byte.
2. Persistence
This is similar to what geohot did in https://crbug.com/351788
Snippet from /etc/init/ui-collect-machine-info.conf:
env UI_MACHINE_INFO_FILE=/var/run/session_manager/machine-info
dump_vpd_log --full --stdout > "${UI_MACHINE_INFO_FILE}"
The exploit symlinks machine-info to /run/modprobe.d which is a configuration file for modprobe. dump_vpd_log writes /mnt/stateful_partition/unencrypted/cache/vpd/full-v2.txt into /run/modprobe.d. The exploit places the "install modulename command..." clause into full-v2.txt to launch a command at boot.
There are difficulties though and the exploit uses symlinks extensively to overcome them. Here is a list:
1) /var/run/session_manager/machine-info -> /run/modprobe.d
Written to by /etc/init/ui-collect-machine-info.conf
2) /var/run -> /var/real_run
/var/run normally points to /run tmpfs, so redirect it to a stateful partition
3) /var/log -> /run
login_manager creates the /var/log/chrome directory. Use it to create the /run/chrome directory.
4) /mnt/stateful_partition/unencrypted/preserve/attestation.epb -> /dev/net/
/etc/init/cryptohomed.conf moves /mnt/stateful_partition/home/.shadow/attestation.epb to /mnt/stateful_partition/unencrypted/preserve/attestation.epb. Use it to move a device file into /dev/net.
5) /var/lib/metrics/uma-events -> /dev/net/attestation.epb
The uma-events file is often accessed by metrics. Link it to attestation.epb device file. Accessing the device triggers modprobe.
See writeup.pdf for details.
Running the exploit:
1) Optionally place any ssh keys to be authorized into drop/authorized_keys.
2) Run ./server.py on a linux machine from the crosxpl directory.
3) Double check that chromebook is up to date, platform version 8530.81.0, wolf.
4) Navigate to server-ip:8000 in guest mode. Calc should pop.
5) Reboot and enter guest mode. Calc should pop.
I've tested it on a Dell Chromebook 11, board name wolf. Some offsets may need to be adjusted for other models. It's a memory corruption exploit and the stability is about 90%. Sometimes shill hangs to the point of not accepting proxy connections. With bad luck you may have to reboot to retry.
Chrome: 53.0.2785.103 stable
Platform: Chrome OS, wolf, 8530.81.0

rickyz: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

rickyz: Uh oh! This issue still open and hasn't been updated in the last 28 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?
If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?
If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We commit ourselves to a 30 day deadline for fixing for critical severity vulnerabilities, and have exceeded it here. If you're unable to look into this soon, could you please find another owner or remove yourself so that this gets back into the security triage queue?
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hey mnissler! Could please you update the status here? One of the blocking issues is unassigned and the other hasn't had activity for over a month.
Is this still P0/Severity-critical? Or has a mitigation been put in place, in which case maybe we should open a different bug?
Thanks!

Current status: Mitigation is in place, my plan was to wait for the shill work to complete before we mark this fixed and open the bug. Relabeling accordingly. I'll ping the shill folks again to hopefully get some traction.