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:
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}")}
endThe 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.
Are you from SOC, Threat Research, or DFIR departments? If so, you can join an online community of 400,000 independent security researchers:
If you want to test all these features now with completely free access to the sandbox:
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.
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
SpyLoan apps, a type of PUP, are rapidly increasing, exploiting social engineering to deceive users…
CyberVolk, a politically motivated hacktivist group, has leveraged readily available ransomware builders like AzzaSec, Diamond,…
A ransomware attack on Blue Yonder, a leading supply chain management software provider, has created…
Dell Technologies has released a security update for its Wyse Management Suite (WMS) to address…
The Cybersecurity and Infrastructure Security Agency (CISA) recently detailed findings from a Red Team Assessment…
IBM has issued a security bulletin warning customers about a vulnerability in its Workload Scheduler…