JudgeO Online Code Editor Flaw Let Attackers Execute Code

A critical flaw has been identified in the popular online code editor, JudgeO.

If exploited, this vulnerability could allow attackers to execute arbitrary code with root-level privileges, posing a significant threat to systems and data integrity.

Is Your Network Under Attack? - Read CISO’s Guide to Avoiding the Next Breach - Download Free Guide

The vulnerability, tracked under the identifier, was discovered in the JudgeO online code editor, as reported by GitHub.

This tool, widely used by developers and educational institutions for coding and testing purposes, has been found to contain a severe security flaw that malicious actors could exploit.

This release fixes the following security vulnerabilities:

• CVE-2024-28185
• CVE-2024-28189
• CVE-2024-29021

CVE-2024-28185: Sandbox Escape via Symbolic Link

The issue’s core lies in the application’s handling of symbolic links (symlinks) within the sandbox directory.

Attackers can exploit this oversight by creating symlinks that point to critical system files.

Details:

When JudgeO writes a run_script to the sandbox directory, it inadvertently writes to these linked system files instead due to the symlink.

unless submission.is_project

      # gsub is mandatory!

      command_line_arguments = submission.command_line_arguments.to_s.strip.encode("UTF-8", invalid: :replace).gsub(/[$&;<>|`]/, "")

      File.open(run_script, "w") { |f| f.write("#{submission.language.run_cmd} #{command_line_arguments}")}

    end

The vulnerability manifests when executing a submission. JudgeO’s process involves writing a run_script to the sandbox directory.

However, if an attacker has already placed a symlink at the run_script path, the f.write operation in the code will write to an arbitrary file on the system that is not sandboxed.

This security gap allows an attacker to overwrite system scripts and achieve code execution outside the confines of the sandbox environment.

CVE-2024-28189: Sandbox Escape Patch Bypass via chown running on Symbolic Link

The vulnerability stems from the application’s  chown command on files within the sandbox that users can manipulate.

Attackers can exploit this by creating a symbolic link (symlink) from within the sandbox to a file outside.

This allows the chown command, intended only for internal sandbox operations, to be executed on any file on the system.       

Details:

The specific issue arises in the context where the application attempts to change the ownership of a file name run_script, which is crucial for the execution of user-submitted code.

The relevant code snippet is as follows:

`sudo chown $(whoami): #{run_script} && rm #{run_script}` unless submission.is_project

This command is executed unless the submission is marked as a project.

By strategically creating a symlink named run_script that points to a critical system file, an attacker can force the application to change the ownership of an external file, effectively gaining control over it.

CVE-2024-29021: SSRF into Sandbox Escape through Unsafe Default Configuration

The vulnerability is rooted in Judge0’s default configuration, particularly its handling of network requests within the sandboxed environment.

This configuration flaw can be exploited via SSRF, an attack where an attacker induces the server-side application to make requests to an unintended location.

Details:

Judge0 includes a configuration option labeled enable_network, which, when enabled, allows the sandboxed application to perform network requests.

This includes communication with internal services such as Judge0’s PostgreSQL database, accessible within the internal Docker network.

The exploit targets the following critical lines of code:

command = "isolate #{cgroups} 

    -s 

    -b #{box_id} 

    -M #{metadata_file} 

    #{submission.redirect_stderr_to_stdout ? "--stderr-to-stdout" : ""} 

    #{submission.enable_network ? "--share-net" : ""} 

    -t #{submission.cpu_time_limit} 

    -x #{submission.cpu_extra_time} 

    -w #{submission.wall_time_limit} 

    -k #{submission.stack_limit} 

    -p#{submission.max_processes_and_or_threads} 

    #{submission.enable_per_process_and_thread_time_limit ? (cgroups.present? ? "--no-cg-timing" : "") : "--cg-timing"} 

    #{submission.enable_per_process_and_thread_memory_limit ? "-m " : "--cg-mem="}#{submission.memory_limit} 

    -f #{submission.max_file_size} 

    -E HOME=/tmp 

    -E PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" 

    -E LANG -E LANGUAGE -E LC_ALL -E JUDGE0_HOMEPAGE -E JUDGE0_SOURCE_CODE -E JUDGE0_MAINTAINER -E JUDGE0_VERSION 

    -d /etc:noexec 

    --run 

    -- /bin/bash run 

    < #{stdin_file} > #{stdout_file} 2> #{stderr_file} 

    "

 

    puts "[#{DateTime.now}] Running submission #{submission.token} (#{submission.id}):"

    puts command.gsub(/s+/, " ")

    puts

 

    `#{command}`

This command setup is generally secure against command injection vulnerabilities, as all variables injected into the shell command are controlled (either string literals or numerical values).

However, the SSRF vulnerability allows an attacker to manipulate these settings by interacting with the database to change the data types of relevant columns, potentially leading to command injection.

This incident serves as a stark reminder of the importance of cybersecurity vigilance.

As the developers of JudgeO have demonstrated, prompt action and transparency in addressing security issues are critical.

Users, for their part, must remain proactive in updating their software and staying informed about potential vulnerabilities.

Combat Email Threats with Easy-to-Launch Phishing Simulations: Email Security Awareness Training -> Try Free Demo