CVE-2024-35122 - Local DoS Vulnerability in IBM i 7.x – Exploit Details & Practical Guidance

There’s a newly disclosed local Denial of Service (DoS) security vulnerability, CVE-2024-35122, affecting IBM i operating system versions 7.2, 7.3, 7.4, and 7.5. The issue: a local, non-privileged user can exploit insufficient authorization checks to create referential constraints using the higher-level privileges of another user — potentially locking or disrupting access to important files. This write-up will explain the vulnerability in simple terms, walk you through the basics, show you exploit details (with code!), and give pointers to official references.

What Is IBM i and What’s the Problem?

IBM i (formerly known as AS/400 or iSeries) is a business system known for its rock-solid reliability, but like anything, it’s not bulletproof. The system’s database management system, Db2 for i, allows users to define "referential constraints" — rules that bind two database tables together, often for data consistency.

The bug: The authority checks when creating these constraints aren’t strict enough. A regular user can potentially trick a privileged user (maybe a DBA or an admin) into running code to add a referential constraint on a file. With this, the regular user can make changes that affect file accessibility — even locking files against other users (including the rightful file owner!).

The official IBM advisory

- IBM Security Bulletin: IBM i is vulnerable to file level Denial of Service (CVE-2024-35122)

Where’s the Flaw?

- If a non-privileged user wants to set up a referential constraint between tables, they should need the proper authorities on both the referencing and referenced file (IBM lingo for "tables").
- But IBM i versions 7.2–7.5 miss part of this check. So, it’s possible for a user with little access to ask a more privileged user to run code that sets up referential constraints in their own privilege context.
- Once the constraint is set, the regular user can perform certain actions (like inserting or deleting rows), and suddenly the underlying table might become unavailable or locked, breaking business apps and causing headaches.

Example: How Could Someone Exploit This?

Suppose Alice is a regular user on the system. Bob is an admin or DBA with higher privileges. Alice convinces (or tricks) Bob into running an SQL script:

-- Malicious SQL statement
ALTER TABLE LIBRARY1.TABLE_A
ADD CONSTRAINT MAL_REF_CONSTRAINT
FOREIGN KEY (COL_X)
REFERENCES LIBRARY2.TABLE_B (COL_Y)
ON DELETE RESTRICT;

If Bob inadvertently runs this script on behalf of Alice (maybe via a change request, or through a maintenance job), the referential constraint is created *using Bob’s privileges*.

Now Alice can perform insert, update, or delete operations in a way that causes TABLE_B to be locked or trigger constraint rules. This effectively turns Alice’s low privileges into a tool to deny access or create disruption for everyone needing TABLE_B.

Weaponizing the Vulnerability: Step-by-Step Example

Here’s a simplified walkthrough (DO NOT attempt this on production — this is for educational awareness only!):

Regular user creates a "known" table and prepares a script that appears harmless.

2. Privileged user (target) is tricked into running the script, which actually sets up a referential constraint involving a table the regular user shouldn’t have control over.
3. Regular user now initiates operations (inserts/deletes) that invoke constraint enforcement, potentially causing locking or accessibility issues for the referenced file (denial of service).

Simplified pseudo-code

-- Alice (low-priv user) prepares to exploit

-- Alice owns: ALICEDATA.CANNED_TABLE
-- Target table (Bob owns): BOBDATA.CRITICAL_TABLE

-- Step 1: Write a SQL script for Bob to execute
ALTER TABLE ALICEDATA.CANNED_TABLE
ADD CONSTRAINT ABUSE_CONSTR
FOREIGN KEY (ID)
REFERENCES BOBDATA.CRITICAL_TABLE (BOB_ID);

-- Step 2: Bob (with more authority) runs above SQL script

-- Step 3: Alice locks BOBDATA.CRITICAL_TABLE by inserting rows that
-- trigger the constraint but don't match referenced keys.
INSERT INTO ALICEDATA.CANNED_TABLE (ID)
VALUES ('SomeBadValue');

-- This may result in constraint failures, locking, or tables being tied up in validation

What Makes This Dangerous?

- No need for remote exploit or admin access. Any local user can start the attack by scripting and social engineering.
- DoS with regular user rights. You don’t need to own or even see the target file — just trick someone who can.

Old and new versions at risk. It’s present all the way from 7.2 to 7.5.

- Automatable. An attacker could automate the generation of scripts targeting different data files.

How to Stay Safe

- Patch now! IBM has released PTFs for affected versions. Find your version and get the fix here:
IBM Security Bulletin

References

- NIST CVE Entry: CVE-2024-35122
- IBM Security Bulletin (Official)
- IBM i Documentation on Referential Constraints

Conclusion

CVE-2024-35122 is an example of how even “insider” attacks with basic authority can escalate into much bigger business disruptions using features like referential constraints. Patch ASAP, train your teams, and strengthen processes to prevent social engineering — it’s the best defense.

Stay secure, and always double-check those SQL scripts!

Timeline

Published on: 01/24/2025 18:15:31 UTC