The inital vulnerability here is an unbounded sscanf into a stack variable. In terms of discovery just checking those format strings for unbounded string reads will find plenty of bugs out there in the world. Looking at the exploit I assume the stack was not executable since they use a minimal rop chain, though its not explicitly stated.

Using this to launch telnetd with the default credentials (root:123456) results in a restricted shell (uvsh) that can write to /tmp only.

In theory this might be sufficent, but, for any developers out there, if you’re going to use a restricted shell, you probably shouldn’t store important scripts under /tmp also…One could modify the script at /tmp/bin/reboot.sh to get execution in an unrestricted context.

An integer overflow in Adobe Reader’s parsing of gesture coordinates.

The document.addAnnot function takes in an object containing various configuration options, including a gestures key which is an array of x and y coordinates for the gesture. In processing this array it appears to have a check along the of

if(last_array_index + 1 < 0x55555)

The problem is that a last array index of -1, because 0xFFFFFFFF, when you add 1 to this, you get 0, which means it passes this apparent size check, despite being over the maximum. The original -1 index is then actually used in calculating an offset leading to an improper this pointer being used.

Basic idea is that the identifier pulled out of a message can point to a different handler between the initial check to redirect the message to the proper “sequence” and that sequence finding the proper endpoint/handler for it.

The flow is that a message comes in on one sequence (A), but the message is for an endpoint on another sequence (B). So A creates a task for B, to handle the message. The handler there just looks up the proper endpoint for the message using an identifier from the original message and calls that identified endpoint.

The problem is that even if A ensures that the endpoint belongs to B when it creates the task and tells B about the message, the endpoint for that identifier can change between task creation and B’s lookup of the endpoint. Leading to the wrong sequence handling the message, which I assume can lead to race condition style issues but I don’t have much knowledge of Chrome internals to comment on that.

The overall issue reminds me of sort-of pid reuse attacks where you have an identifier that code might assume always points to the same thing, not realizing that other programs might start using that pid without your program knowing, and I think thats the main idea to take away here, don’t trust that identifiers won’t be changed out from under you if they are not unique.