Oracle

9 Articles

This Week In Security: What’s In A Name, The AI Bugpocalypse Hits Everyone, OpenWRT Flaws, And Duress Passwords

July 31, 2026 by 23 Comments

The great thing about standards is there’s so many to pick from, right?. (Insert obligatory XKCD #927 here.) Several companies have developed naming schemes to refer to groups of attacks, and now Google has too.

Sometimes, malware, ransomware, or exploit groups name themselves: “Shinyhunters”, “LapSus$”, “Cl0p”, “Lockbit”, and so on. For the groups that don’t advertise their presence, identification and naming can be more difficult. Mostly state-run affairs that didn’t want to draw attention to themselves, these Advanced Persistent Threats (APT) groups were originally simply given numbers. APT28 refers to the Russian GRU Intelligence Directorate suspected of hacking the Democratic Party email servers, APT38 is a North Korean governmental agency involved in financial and crypto currency theft.

Multiple companies and agencies have developed naming schemes to make referring to threat groups easier, typically including a regional identifier as well. CrowdStrike naming uses name groups like “Bear” group for suspected Russian actors, “Panda” for China, “Spider” for unattributed crime groups, while Microsoft uses “Blizzard”, “Typhoon”, and “Tempest”.

Google, deciding there weren’t enough classifications already, now introduces “RELIC”, “CASTLE”, and “COMET”. Of course, each naming organization has dozens of other classification groups as well, but now the next time you hear about an attack being attributed to “Scattered Spider” you know it’s the CrowdStrike name for a crime group.

Critical OpenWRT DHCP Flaw Fixed

The Hacker News reports on a major release of OpenWRT which includes fixes to the odhcpd server, the embedded DHCPv4 and DHCPv6 server written by OpenWRT.

The bug is a straight-forward stack style attack where a buffer is allocated, but not length-checked against the data required to reply to a malformed request. OpenWRT runs on a wide range of devices, but one of the most popular legacy platforms still in use, the MIPS processor architecture, lacks most modern security protections against stack-based attacks, making this attack sting more than it might on other architectures.

The latest OpenWRT releases also fix issues in the uhttpd embedded web server, multiple issues in the LUCI web configuration interface that allowed attackers to inject cross-site scripting content and Linux kernel security fixes. If you run a direct OpenWRT build on your equipment, update! These bugs will have an extremely long tail however, with tens of thousands, or likely more, OpenWRT-based devices that will never see updates.

The company behind several of the findings, Hacker House, say they used multiple AI tools and both open and frontier models to discover the bugs, then manual review and testing to confirm before reporting.

Cisco to Stop Assigning (some) CVEs

Cisco has announced it is moving to a twice-monthly patch cycle. Additionally, Cisco will no longer assign CVEs to each bug in the release.

Cisco says this is in reaction to the rapid increase in bugs found by AI tools, and that “Assessing security risk CVE-by-CVE and applying point mitigations is no longer fit for purpose.” Cisco will still assign a CVE to a bug that “requires compensating controls” or is known to be exploited.

It seems like it will be business as usual for the most severe bugs, but it will be interesting to see what happens when exploits are found for bugs which did not get a CVE in a prior release.

Microsoft Suggests Three-Day Patch Race

Microsoft is now recommending a 3 day patch window for new patches. This is, to say the least, an “aggressive” schedule for applying new patches, given the recent track record of issues introduced by patches.

A update that crashes is inconvenient on a home computer — even more so if it’s your parent’s computer — but could be catastrophic when it brings down an entire corporate fleet. Most large organizations have their own internal patch schedules and internal testing requirements before patches are deployed, delaying the patch process further.

Systems like the CISA KEV database, a list of vulnerabilities known to be actively exploited, are in place to help identify the most important issues. With repeated record-breaking numbers of vulnerabilities pushed in Patch Tuesday and the decreasing support of the KEV and related vulnerability indexing systems, the load on IT departments and administrators is becoming impossible.

The AI “bugpocalypse” is finding record numbers of vulnerabilities, while also closing the timeline between bug to exploit to hours in some cases. The time between bug and exploit then drives the patch cycle, which means less testing. With less testing, the patches are less stable, leading to less trust in rapidly installing them.

Oracle Patches Almost 1500 CVEs

Moving directly from the impacts of the flood of Microsoft security issues, the July 2026 patch set from Oracle included fixes for 1499 security issues and 1434 CVEs over 334 Oracle products.

Oracle is also pressuring administrators to move to a monthly patch cycle, but acknowledges “transitioning to a monthly security patching cadence may require updates to existing operational processes”. Not to worry – there is a Oracle consulting service you can hire to help you patch your Oracle problems.

Linux Patches 323 CVEs in Two Days

After announcing over 400 CVEs in the Linux kernel last week, Linux mainters have announced an additional 323 in the last three days alone. The vulnerabilities cover Bluetooth, Ethernet, USB gadget mode, WiFi drivers, virtualization systems, SMB file sharing, and of course more.

One benefit to the architecture of the Linux kernel is that typically all the fixes will arrive in a single kernel update, but when almost every week brings critical updates and a new kernel, patch fatigue is a real thing. Either users stop applying every update, or the uptime and testing requirements of a company prohibits constantly updating and changing servers.

Duress Passwords Aren’t Necessarily a Good Thing

The security-hardened Android variant Graphene, is in the news this week for the use of duress passwords.

A duress password is a mechanism where a second PIN or password can be used to initiate a device wipe. The hope is that in a situation where you are compelled to unlock a device, providing a password which then wipes the device is a preferable option.

The legality of a duress password depends on the environment it is used in. The United States Customs and Border Patrol claims that by wiping a device during an inspection at the US border, Samuel Tunick destroyed evidence and property in violation of federal laws. The issue is compounded because the stop happened at a border, where many US laws against search, seizure, and the availability of a lawyer are suspended, even for US citizens.

The inclusion of duress passwords, and their cousin hidden encrypted volumes, can sound like a good idea, but can place users in serious danger when in situations with less strict rules of law. Having the ability to wipe data sounds great in isolation, but protestors, human rights workers, and other targeted groups have faced direct and physical threats under some regimes. Facing retaliation for wiping a device, or facing physical violence before providing an unlock code out of fear that it might wipe a device, can be a real risk for some.

FreeBSD Fixes a WireGuard Bug

FreeBSD has issued a security update pertaining to the WireGuard VPN implementation.

WireGuard is a modern VPN with excellent performance even on low-end systems, and which has implementations on basically every platform. The FreeBSD implementation, however, didn’t fully validate VPN packets, accepting packets without checking one of the cryptographic validation measures.

Attackers are able to inject data to a FreeBSD WireGuard implementation if they are able to guess some attributes of the connection, and able to fully modify the data in the VPN if they are able to intercept the packets.

The bug impacts any FreeBSD user of WireGuard. FreeBSD has released updated kernels.

This Week In Security: Another Linux Exploit, Ubuntu Knocked Offline, Finals Interrupted, And Backdoored Tools

May 8, 2026 by 15 Comments

After the CopyFail vulnerability gave root access from any user on almost all distributions last week, this week we’ve got DirtyFrag. This chains the vulnerability in CopyFail (xfrm-ESP) and a new vulnerability in a RPC function which allows similar overwriting of the page cache.

Both vulnerabilities manipulate the Linux page cache where data from disk is stored for rapid access. The kernel will always prefer the cached version of a file, which means that anything that is able to manipulate the contents of the cache can effectively replace the contents of the file. Both of the vulnerabilities leverage a similar mechanism – picking a binary which is flagged to run as root, such as su, and replacing the contents that would prompt for the users password with a launcher to immediately run a shell.

Like CopyFail, DirtyFrag requires the ability to execute code on the target in the first place, but turning almost any code or command execution vulnerability in any network service into root raises the impact significantly, allowing an attacker to break out of containers and privilege environments, or establish a persistent presence in the system when the original vulnerabilities are discovered and closed.

The previous mitigations to block specific kernel modules related to CopyFail are not sufficient to block the new vulnerabilities. At the time of writing this, there are no available patches from the distributions, however the vulnerable kernel modules can be temporarily disabled.

CopyFail added to KEV

CISA (the United States cyber security agency) has added CopyFail to the KEV, or Known Exploited Vulnerabilities list. Attacks on the KEV have been observed under active exploitation, which in the case of CopyFail is hardly a surprise.

The KEV is designed as a tool to allow security teams in government and commercial industry to prioritize the highest risk vulnerabilities – or at least give another source of data to point at when you say “we really need to patch this now”.

Prolonged Ubuntu DDOS

On the heels of the CopyFail vulnerability impacting almost all distributions, Ubuntu has had to face a prolonged distributed denial-of-service (DDoS) attack against the main infrastructure. Ars Technica reported at the beginning of the attack, and after several days, services appear to be restored. In the meantime, core services such as package updates, core repositories, and even the Ubuntu and Canonical websites were largely unreachable.

An Iraqi group claims responsibility for the attack, but it is unclear if they were the actual perpetrators – or why. The timing with the CopyFail vulnerability seems like an opportune moment to cause chaos by taking the update mechanisms of a major distribution offline, but in the era of modern Internet behavior, it could also just have been a Tuesday.

Continue reading “This Week In Security: Another Linux Exploit, Ubuntu Knocked Offline, Finals Interrupted, And Backdoored Tools” →

This Week In Security: Target Coinbase, Leaking Call Records, And Microsoft Hotpatching

April 4, 2025 by 2 Comments

We know a bit more about the GitHub Actions supply chain attack from last month. Palo Alto’s Unit 42 has been leading the charge on untangling this attack, and they’ve just released an update to their coverage. The conclusion is that Coinbase was the initial target of the attack, with the open source agentkit package first (unsuccessfully) attacked. This attack chain started with pull_request_target in the spotbugs/sonar-findbugs repository.

The pull_request_target hook is exceptionally useful in dealing with pull requests for a GitHub repository. The workflow here is that the project defines a set of Continuous Integration (CI) tests in the repository, and when someone opens a new Pull Request (PR), those CI tests run automatically. Now there’s an obvious potential problem, and Github thought of it and fixed it a long time ago. The GitHub Actions are defined right in the repository, and letting any pull request run arbitrary actions is a recipe for disaster. So GitHub always uses actions as they are defined in the repository itself, ignoring any incoming changes in the PR. So pull_request_target is safe now, right? Yes, with some really big caveats.

The simplest security problem is that many projects have build scripts in the repository, and those are not considered part of GitHub Actions by GitHub. So include malicious code in such a build script, make it a PR that runs automatically, and you have access to internal elements like organization and repository secrets and access tokens. The most effective mitigation against this is to require approval before running workflows on incoming PRs.

So back to the story. The spotbugs/sonar-findbugs repository had this vulnerability, and an attacker used it to export secrets from a GitHub Actions run. One of those secrets happened to be a Personal Access Token (PAT) belonging to a spotbugs maintainer. That PAT was used to invite a throwaway account, [jurkaofavak], into the main spotbugs repository. Two minutes after being added, the [jurkaofavak] account created a new branch in spotbugs/spotbugs, and deleted it about a second later. This branch triggered yet another malicious CI run, now with arbitrary Github Actions access rather than just access through a build script. This run leaked yet another Personal Access Token, belonging to a maintainer that worked on both the spotbugs and reviewdog projects. Continue reading “This Week In Security: Target Coinbase, Leaking Call Records, And Microsoft Hotpatching” →

This Week In Security: Oracle Opera, Passkeys, And AirTag RFC

May 5, 2023 by 10 Comments

There’s a problem with Opera. No, not that kind of opera. The Oracle kind. Oracle OPERA is a Property Management Solution (PMS) that is in use in a bunch of big-name hotels around the world. The PMS is the system that handles reservations and check-ins, talks to the phone system to put room extensions in the proper state, and generally runs the back-end of the property. It’s old code, and handles a bunch of tasks. And researchers at Assetnote found a serious vulnerability. CVE-2023-21932 is an arbitrary file upload issue, and rates at least a 7.2 CVSS.

It’s a tricky one, where the code does all the right things, but gets the steps out of order. Two parameters, jndiname and username are encrypted for transport, and the sanitization step happens before decryption. The username parameter receives no further sanitization, and is vulnerable to path traversal injection. There are two restrictions to exploitation. The string encryption has to be valid, and the request has to include a valid Java Naming and Directory Interface (JNDI) name. It looks like these are the issues leading Oracle to consider this flaw “difficult to exploit vulnerability allows high privileged attacker…”.

The only problem is that the encryption key is global and static. It was pretty straightforward to reverse engineer the encryption routine. And JDNI strings can be fetched anonymously from a trio of endpoints. This lead Assetnote to conclude that Oracle’s understanding of the flaw is faulty, and a much higher CVSS score is appropriate. Particularly with this Proof of Concept code, it is relatively straightforward to upload a web shell to an Opera system.

The one caveat there is that an attacker has to get network access to that install. These aren’t systems intended to be exposed to the internet, and my experience is that they are always on a dedicated network connection, not connected to the rest of the office network. Even the interconnect between the PMS and phone system is done via a serial connection, making this network flaw particularly hard to get to. Continue reading “This Week In Security: Oracle Opera, Passkeys, And AirTag RFC” →

OpenOffice Or LibreOffice? A Star Is Torn

November 2, 2020 by 105 Comments

When it comes to open source office suites, most people choose OpenOffice or LibreOffice, and they both look suspiciously similar. That isn’t surprising since they both started with exactly the same code base. However, the LibreOffice team recently penned an open letter to the Apache project — the current keepers of OpenOffice — asking them to redirect new users to the LibreOffice project. Their logic is that OpenOffice has huge name recognition, but hasn’t had a new major release in several years. LibreOffice, on the other hand, is a very active project. We could argue that case either way, but we won’t. But it did get us thinking about how things got here.

It all started when German Marco Börries wrote StarWriter in 1985 for the Zilog Z80. By 1986, he created a company, Star Division, porting the word processor to platforms like CP/M and MSDOS. Eventually, the company added other office suite programs and with support for DOS, OS/2, and Windows, the suite became known as StarOffice.

The program was far less expensive than most competitors, costing about $70, yet in 1999 that price point prompted Sun Microsystems to buy StarOffice. We don’t mean they bought a copy or a license, they bought the entire thing for just under $74 million. The story was that it was still cheaper than buying a license for each Sun employee, particularly since most had both a Windows machine and a Unix machine which still required some capability.

Sun in Charge

Sun provided StarOffice 5.2 in 2000 as a free download for personal use, which gave the software a lot of attention. It eventually released much of the code under an open source license producing OpenOffice. Sun contributed to the project and would periodically snapshot the code to market future versions of StarOffice.

This was the state of affairs for a while. StarOffice 6.0 corresponded to OpenOffice 1.0. In 2003, release 1.1 turned into StarOffice 7. A couple of years later, StarOffice 8/OpenOffice 2.0 appeared and by 2008, we had StarOffice 9 with OpenOffice 3.0 just before Oracle entered the picture.

Continue reading “OpenOffice Or LibreOffice? A Star Is Torn” →

Researchers Break FPGA Encryption Using FPGA Encryption

April 23, 2020 by 18 Comments

FPGAs are awesome — they can be essentially configured into becoming any computing device you want. Simply load your selected bitstream into the device on boot, and it behaves like a different piece of hardware. With great power comes great responsibility.

You might try to hack a given FPGA system by getting between the EEPROM that stores the bitstream and the FPGA during bootup, but FPGA manufacturers are a step ahead of you. Xilinx 7 series FPGAs have an onboard encryption and signing engine, and facilities for storing a secret key. Once the security bit is set, bitstreams coming in have to be encrypted to protect from eavesdropping, and HMAC-signed to assure that they are authentic. You can’t simply read the bitstream in transit or inject your own.

Researchers at Ruhr University Bochum and Max Planck Institute for Cybersecurity and Privacy in Germany have figured out a way to use the FPGA’s own encryption engine against itself to break both of these security guarantees for the entire mainstream 7-series. The attack abuses a MultiBoot function that allows you to specify an address to begin execution after reboot. The researchers send 32 bits of the encoded payload as a MultiBoot address, the FPGA decrypts it and stores it in a register, and then resets because their command wasn’t correctly HMAC signed. But because the WBSTAR register is meant to be readable on boot after reset, the payload is still there in its decrypted form. Repeat for every 32 bits in the bitstream, and you’re done.

Pulling off this attack requires physical access to the FPGA’s debug pins and up to 12 hours, so you only have to worry about particularly dedicated adversaries, but the results are catastrophic — if you can reconfigure an FPGA, you can make it do essentially anything. Security-sensitive folks, we have three words of consolation for you: “restrict physical access”.

What does this mean for Hackaday? If you’re looking at a piece of hardware with a hardened Xilinx 7-series FPGA in it, you’ll be able to use it, although it’s horribly awkward for debugging due to the multi-hour encryption procedure. Anyone know of a good side-channel bootloader for these chips? On the other hand, if you’re just looking to dig secrets out from the bitstream, this is a one-time cost.

This hack is probably only tangentially relevant to the Symbiflow team’s effort to reverse-engineer an open-source toolchain for this series of FPGAs. They are using unencrypted bitstreams for all of their research, naturally, and are almost done anyway. Still, it widens the range of applicability just a little bit, and we’re all for that.

[Banner image is a Numato Lab Neso, and comes totally unlocked naturally.]

Oracle V Google Could Chill Software Development

March 30, 2018 by 96 Comments

Unless you’ve completely unplugged from the news, you probably are aware that the long-running feud between Oracle and Google had a new court decision this week. An appeal court found that Google’s excuse of fair use wasn’t acceptable and that they did infringe on Oracle’s copyrights to Java. Oracle has asked for about $9 billion in damages, although the actual amount is yet to be decided. In addition, it is pretty likely Google will take it up to the Supreme Court before any actual judgment is levied.

The news is aimed at normal people, so it is pretty glossy about what exactly happened. We set out to try to make sense of it all. We found a pretty good article from [Michaela Barry] about what the courts previously found.  There were three main parts:

  • There were 37 API (Application Programming Interface) declarations taken verbatim from Java. This would be like a C header file if you aren’t familiar with Java.
  • Google decompiled 8 security files and used them.
  • The rangeCheck function — 9 lines of Java code — were exactly the same in Oracle’s Java and Android.

Continue reading “Oracle V Google Could Chill Software Development” →