Filter bypass flaw is triggered only on very large user input, which puts restrictions on its exploitability
A bug in one of PHP’s functions made it possible to bypass security measures meant to protect web applications against malicious user input, a security researcher has found.
filter_var() is a popular function that enables developers to sanitize and validate strings for different data formats such as email addresses, web domains, and URLs.
However, according to the findings of security researcher Jordy Zomer, the function had an integer wraparound flaw that, when triggered, caused the program to bypass filtering logic.
Signed and unsigned integers
filter_var() takes an input string and a numeric argument that determines the string’s length. The function signature defined the length argument as a ‘signed integer’, which splits the variable range between negative and positive values.
However, another length variable declared inside the function body was defined as an unsigned integer, which only accepts positive values. The mismatch between the signed and unsigned declarations could cause erratic behavior when the function was provided with very large strings, and caused the program flow to jump over the branch of instructions that applied filters for the hostname and domain flags (FILTER_VALIDATE_DOMAIN and FILTER_FLAG_HOSTNAME).
“Due to the fact that the filter is no longer valid, any code that relies on it as a security check may be bypassed, resulting in the introduction of bugs into your code,” Zomer told The Daily Swig.
“In the course of researching filter_var in conjunction with these flags, I discovered that it is used in combination with these flags quite frequently.”
RECOMMENDED Critical SQL injection flaw fixed in Rapid7’s Nexpose vulnerability scanner
The bug could also be used to stage denial-of-service (DoS) attacks against PHP web servers with data slightly larger than 2GB.
“My best advice is that it is really crucial that you always utilize the appropriate escaping mechanisms when putting something in a different context than it was before,” Zomer said.
“Another point to emphasize is that filtering your input is never an effective way of preventing vulnerabilities, because different situations call for different escaping strategies.”
Limited impact
The filter bypass flaw is triggered only on very large user input, which imposes severe restrictions on its exploitability.
“This bug is unlikely to have a wide impact, because [of] the basic fact that it only influences one specific subfunction in one specific function (namely, domain name filtering), and it requires over 4GB variable size to be supplied to trigger it,” Stanislav Malyshev, developer at PHP internals, told The Daily Swig.
“Any properly configured PHP application should have memory limits and input controls that do not allow 4GB input data for domain names – for the simple reason there’s no legitimate data that could have 4GB domain names.”
Challenges of maintaining volunteer projects
According to Malyshev, the fix has already been checked into the PHP source on March 28, and will be part of the next scheduled formal PHP release.
Zomer, who was not satisfied with the speed of the PHP security team, went ahead and published his own fix for the bug on his website.
“What my patch does is modify the length argument of the _php_filter_validate_domain function to size_t instead of int,” he said. “This converts it to an unsigned integer of the appropriate type and avoids it from wrapping around to a negative number or zero.”
Malyshev confirmed that Zomer reported the bug on March 2, but it took a few days to clarify the details, and they were given about two weeks before Zomer published the write-up on his website.
“I personally consider a two-week lead not enough for a volunteer project, where people can be busy, have vacations, have personal lives, etc and are not paid for being on-call for every issue,” he said.
“In fact, many large enterprises with hundreds of people being paid to do this take longer to release fixes.”
Read more of the latest infosec research news from around the world
Malyshev also questioned some of the claims made in Zomer’s write-up, including a proof-of-concept that suggests the bug can be used for arbitrary code execution on the PHP server.
“I would prefer the author to have a bit more patience and not to rush with the disclosure,” he said.
Zomer said: “It’s important to note that both sides made blunders in fairness. They should have responded more quickly, and I should have been more patient and explicit about my expectations from the beginning.
“In retrospect, I should have handled the situation differently. However, I am currently developing a coordinated disclosure policy in order to avoid such mistakes from occurring on my end in the future.”
DON’T FORGET TO READ Latest web hacking tools – Q2 2022
