This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
With only two of many reported vulnerabilities fixed in Oracle's latest update, the database security community questions Oracle's patch bottleneck.
Oracle's Tuesday release of its critical patch update (CPU) garnered a continuation of criticism from the database security community, with researchers pointing to a mounting list of unfixed vulnerabilities that date back to 2009, even as Oracle's rate of releasing database patches continues to plummet. Not counting MySQL updates, which are primarily handled by the open-source community, only two out of the 78 fixes in Tuesday's CPU were database-related, the lowest number released by Oracle since it started quarterly CPU releases.
"I am honestly shocked that they only fixed two database vulnerabilities," said Alex Rothacker, manager of Application Security's research arm, TeamSHATTER.
According to Rothacker, his firm currently has nine vulnerabilities reported in Oracle's queue of discovered vulnerabilities. While that might not seem like a lot on its face, he said, one of them dates back to 2009 and five of them can result in privilege escalation. In addition, that's only the vulnerabilities discovered by AppSec researchers. Based on his conversations with those in the community, Oracle has been notified by other vendors and independent researchers about many other vulnerabilities, as well.
"There's definitely more stuff out there than just those nine," Rothacker said.
Rothacker said that because many Oracle customers are loathe to make fixes in their databases anyhow, this lack of pressure is what allows the firm to "get away with taking its time on these CPUs."
Wolfgang Kandek, CTO of Qualys, tends to agree that the slow speed at which database patches are generally applied could contribute to Oracle slowing down its pace with these updates.
"Database patching is definitely slower than other areas, such as servers or workstations," he said. "You can find vulnerabilities and Oracle can fix them, but if customers do not install them or come back to Oracle and say, 'this is important for me,' it makes sense that Oracle could maintain that flow of patch schedule. The rollout schedule is a reflection of how much users actually pay attention to those things."
However, Amichai Shulman, CTO of Imperva, believes there is a bottleneck in the Oracle patching process that needs fixing.
Database access controls keep information out of the wrong hands. Limit who sees what to stop leaks--accidental and otherwise. Also in the new, all-digital Dark Reading supplement: Why user provisioning isn't as simple as it sounds. Download the supplement now. (Free registration required.)
It certainly is a possibility that Oracle's patch roll-out schedule is affected by how quickly users patch, and in a way that would make sense. On the other hand, it seems to me that something like that shouldn't be a big factor if a known vulnerability is out there. I think vendors should make patches available as soon as they can, and then leave it up to the enterprises to deploy them as they see fit. Brian Prince, InformationWeek/Dark Reading Comment Moderator
2021 Top Enterprise IT TrendsWe've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Building the SOC of the FutureDigital transformation, cloud-focused attacks, and a worldwide pandemic. The past year has changed the way business works and the way security teams operate. There is no going back.
Enterprise Vulnerabilities From DHS/US-CERT's National Vulnerability DatabaseCVE-2021-27225 PUBLISHED: 2021-03-01
In Dataiku DSS before 8.0.6, insufficient access control in the Jupyter notebooks integration allows users (who have coding permissions) to read and overwrite notebooks in projects that they are not authorized to access.
SerComm AG Combo VD625 AGSOT_2.1.0 devices allow CRLF injection (for HTTP header injection) in the download function via the Content-Disposition header.
In SaltStack Salt before 3002.5, eauth tokens can be used once after expiration. (They might be used to run command against the salt master or minions.)
An issue was discovered in SaltStack Salt before 3002.5. Sending crafted web requests to the Salt API can result in salt.utils.thin.gen_thin() command injection because of different handling of single versus double quotes. This is related to salt/utils/thin.py.
To save this item to your list of favorite Dark Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.