Regular Expression DoS:
Regular expressions process input using a remarkably complex non-deterministic finite automaton, which repeatedly processes the input until it makes a match, following different paths through the regular expression and back-tracking where necessary.
In our talk we showed a simple regular expression that could take up 100% of the CPU on your server with only a short input string:
This Bryan Sullivan article covers the hows and whys of ReDoS, and a possible approach for testing a regular expression for the pathological worst case.
We forgot to mention that .NET 4.5 now supports a MatchTimeout property on regular expressions, which means that you can limit the CPU time of regex processing.
Any parsing of untrusted / user submitted files is complicated, and so receiving file uploads is fraught with danger.
In our talks we showed two XML attacks that could happen with just a simple .NET XmlDocument usage:
XmlDocument xmlDoc = new XmlDocument();
XmlPreviewLabel.Text = xmlDoc.DocumentElement.LastChild.InnerText;
The XmlDocument parser in .NET does not safely handle doc types or user-defined entities by default. This can lead to the "Billion Laughs" denial of service attack which chews up CPU and RAM, or to XML external entities reading files from off of disk.
Nazim's Security Blog shows a couple of examples where things can go awry, and gives a list of the .NET API's that are unsafe by default:
- Load and LoadXml UNSAFE unless you pass a safe XmlReader (DTD disabled) into it during initialization.
- InnerXml is NEVER SAFE.
- UNSAFE by default in .NET 3.5 and below.
- You need to set ProhibitDtd=true to make this safe.
- .NET 4.0 and above are safe be default.
- UNSAFE as it supports both entities and XSL script.
- Safe for XSL script since this is blocked by default.
- UNSAFE for entity expansion unless a secure resolver is specified.
- Pass an instance of XmlSecureResolver or null
- NEVER SAFE – supports both entities and XSL script.
Post a Comment
Comments are moderated. Be nice!