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!
How Enterprises are Developing Secure Applications Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Enterprise Vulnerabilities From DHS/US-CERT's National Vulnerability DatabaseCVE-2021-23351 PUBLISHED: 2021-03-08
The package github.com/pires/go-proxyproto before 0.5.0 are vulnerable to Denial of Service (DoS) via the parseVersion1() function. The reader in this package is a default bufio.Reader wrapping a net.Conn. It will read from the connection until it finds a newline. Since no limits are implemented in ...
An issue was discovered in MantisBT before 2.24.5. It associates a unique cookie string with each user. This string is not reset upon logout (i.e., the user session is still considered valid and active), allowing an attacker who somehow gained access to a user's cookie to login as them.
This affects all versions of package github.com/nats-io/nats-server/server. Untrusted accounts are able to crash the server using configs that represent a service export/import cycles. Disclaimer from the maintainers: Running a NATS service which is exposed to untrusted users presents a heightened r...
An issue was discovered in the Linux kernel through 5.11.3. drivers/scsi/scsi_transport_iscsi.c is adversely affected by the ability of an unprivileged user to craft Netlink messages.
An issue was discovered in the Linux kernel through 5.11.3. Certain iSCSI data structures do not have appropriate length constraints or checks, and can exceed the PAGE_SIZE value. An unprivileged user can send a Netlink message that is associated with iSCSI, and has a length up to the maximum length...
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.