You’re a paranoid schizophrenic if you think optionsbleed affects you in any meaningful way beyond what you should have already been aware of, unless you run systems with multiple tenants that upload their own crap to document roots and you’ll happily serve as-is, yet pretend to provide your customers with security; this is a use-after-free with a pre-established boundary, and as such there’s a limited amount of leaked memory. Do you know what may be in this memory? Do you know what a use-after-free is? Hell, do you know why you’re still allowing OPTIONS, or even whether you do?
Don’t get your panties in a wad.
When should you be concerned?
If you have open registration and run document roots for customers that’ll obtain unchecked document roots. The exploit path is active not passive. Furthermore, it requires millions upon millions it not billions upon billions of requests exploiting this undocumented feature, so long as it goes unchecked and unpatched, and if you haven’t noticed any of that increased traffic, you’re being lazy.
To be honest, this isn’t the first security concern you’ve run in to, and it isn’t the first security issue you’re vulnerable to, that will remain exploitable for quite some time, until after someone you rely on fixed the issue for you, meanwhile compromising your customers.
It is that way because you run a service in a saturated market and all you can do is be competitive on price. It’s a free-for-all for anyone with a stolen credit card. It reduces quality, and security. Thanks.
When can you stop being concerned?
First of, all responses for the millions or billions or however many you should have noticed must be analysed, and give a mere indication of one or the other thing out of a pool of hundreds of billions being statistically more likely than the other. Remember, a limited quantity of memory doesn’t tell you what you are reading, how far along you are in reading any of it, or what the context is of what you’re reading.
Is it a small part of the SSL public key? A small part of the web request response? A chunk of the path to the index.php? Or is it a chunk of the database password used? Nobody knows until you get enough data to analyse the results of all data. If you can’t appreciate the maths behind analysing multiple readings of 8 arbitrary bytes, choose another career. Not that I know what to do and how to do it, by the way.
The issue appears to have been discovered and disclosed as early as 2014. Still, some 3 years later, no existing exploits exist that yield anything of value.
Furthermore, the circumstances under which the exploit is actually valid is also very explicit, well known and narrow. These circumstances do not usually occur just out of the blue. Someone has put those circumstances in place (and should have known what they might expose themselves to, since 2014).
Be concerned, still.
If you don’t know what we’re talking about when we say OPTIONS bleeding free-after-use memory to the requester, stop reading and get yourself a professional.
If you do understand the general semantics, then you need to appreciate any customer account with increased traffic over the past
The issue appears to have been discovered and disclosed as early as 2014. Exploits like these take several ingredients to be useful:
- PatienceYou don’t rush a site with too large a number of requests without going undetected.
- AnalysisWhatever data an attacker does obtain is subject to interpretation, with a significant amount of data and computing time required.
- A TargetThis isn’t just a thing that allows you to compromise every other thing on the web; it needs to be aimed at a specific target, where the attacker is able to also upload some code abusing the information that was found, if any.
So, long story short, you need to be concerned if your multi-tenant systems show customers (target) with increased traffic since 2014 (patience).
Thanks for listening to this rant 😉
UPDATE: The fix wasn’t in Fedora Rawhide, 27, 26 nor 25, albeit more recent upstream patches had made it. It’s largely gone unnoticed; so I enquired as to the policy, and moved on to submit the updates:
Good luck!
kanarip 
2 thoughts on “Optionsbleed: Don’t get your panties in a wad”
Comments are closed.