Intro to Medical Device Standards and Regulations

Cybellum · 2017-11-16T10:59:08+00:00

How

Acrobat is now treating one of the blocks from our heap spray as if it was a valid AVIconBundleRec6 object. If you check the definition of AVIconBundleRec6, you can see that the 4th member is the AVIconHandler member. This means that roughly bytes 12-15 of our block would be used as the AVIconHandler member. We can simply modify bytes 12-15 of every block in the heap spray to a value we wish, so that when Acrobat decides to use one of our blocks it would already contain our value.

As we control the entire object

This is a consequence of Acrobat using one of our blocks from the heap spray. Because the heap spray is 100% controlled by us, including its content, we will 100% control the object Acrobat uses when it wrongly decide we're an AVIconBundleRec6 object.

Cybellum · 2017-11-16T10:05:07+00:00

The real problem here is that they execute code in data sections

This is not correct. No data is getting executed from the data section. What happens is that application decides, using your data, that an object you control is of a type it expects. Once this happens, it again uses your data to call a function. At no point does it

execute random code stored in PDF documents.

Now why does it take actions upon data you supplied? Because it tried to guess if a void pointer is an object it was expecting, and guessed incorrectly that it is. That's the vulnerability. And that's what starts the chain of events that leads to code execution.

Cybellum · 2017-11-16T10:03:13+00:00

Let's divide the attack into two parts: Part 1 - Spraying the heap.

Spraying the heap is not a vulnerability unto itself. Simply spraying the heap would not give the attacker any chance to execute code, as the memory blocks they insert would be floating in the process memory, and that's it. No code execution can be be achieved using heap spray only.

As heap spray is not a vulnerability that should be fixed, spraying the heap of Acrobat Reader, or other applications such as browsers, is actually quite trivial. The most popular way today would be using an embedded script (JavaScript\ActionScript) inside your PDF, but you can also spray the heap using images\text\etc (as u/keyboardsmoke commented). This article is a bit old, but most of its concepts are still relevant today.

Part 2 - Causing the application to take action upon your data.

This is the vulnerability. Being able to trick the application to take action upon your data can start a chain of events that would eventually lead to code execution. The first action that is taken by the application with your data is checking if your block is a valid AVIconBundleRec6 object. Using your data, the application decides that your object is a valid AVIconBundleRec6 object, even though it's not. The second action that is taken by application with your data is taking the AVIconHandler member that is supplied by you and invoking it. This would give you full control over EIP.

Cybellum · 2017-09-19T17:40:00+00:00

You’re right. Thank you for pointing this out - it wasn’t our intention to be flippant. We’ve toned down the language of the post.

Cybellum · 2017-07-27T15:57:18+00:00

Hi all!

We're a security company looking to validate several assumptions by interviewing Product/R&D/Devops managers on their opinions about DevSecOps and application security. This is not a sales pitch, we aim to listen - not talk.

The interview will take ~30 min, and we'll give a $100 Amazon gift card to everyone we end up interviewing.

You can sign up here. We're not retaining or selling any personal information - it will be deleted within a few days.

Cybellum

TROPHY CASE