Hello Professor Stein. For a final project at Case Western, I offered
to setup a cluster of SAGE servers for the math department.
Unfortunately, I found that the default server setup is highly
insecure. I would like to collaborate with you and find a way to
modify
the notebook deployment to eliminate some basic (yet severe) security
issues.
Since I'm new to SAGE (and Python, for that matter), I decided that
the
easiest way to determine how to safely deploy a server would be to
login
to a public SAGE server and reverse-engineer its deployment based on
my
queries. Coincidentally, I stumbled upon your server (don't worry --
I
did not execute any malicious commands.) and discovered several
risks.
Using the os module in Python, you can find the following:
1. All of the processes running on the server, as well as the
parameters
used to execute them.
2. The username, uid, groups, gid, etc of the current process.
3. The permissions of large portions of the file system.
4. The operating system the server is deployed on.
5. All of the users on the system.
6. The programs available to the users
7. Services running on the computer
8. Devices attached to the computer (I'm guessing this is a
virtualized
server, though...)
These are just the things I can think of off the top of my head. This
is more than enough information for a hacker to bring down the
server.
Here are just a few potential attacks I can think of:
1. scp appears to be among the available programs in what I'm guessing
was an instance of the virtualized server image. Even if gcc was not
available on the server side (it appears that it is), anyone could
compile an executable on their own system and transfer it to the
server
via scp.
2. Delete any file owned by the server uid. Based on something I read
on your forum, it appears that you used to be able to delete the SAGE
server itself (this was the first exploit I checked for).
3. Kill processes owned by the server uid. This means you could:
- Kill the server
- Create a python script that ruins system resources by (1)
creating
random processes, and (2) killing these with signal 9. Signal 9 does
not properly return resources to the OS, so looping this for a few
minutes will just eat the system.
4. By combining (2) and (3), you can actually bring down the server in
such a way that it will delete all of the user accounts (I tested this
on my own server). Just do the following:
import os;
os.system("rm -Rf ~/.sage/*"); # Destroy the contents of
my .sage folder
os.system("rm -Rf ....../sage_notebook/*") # Destroy the cached
notebook information
os.system("ps -A | grep python"); # Returns a list of python
processes. Based
# upon
the information found in twistd.d, you
# can
easily guess which instance is hosting
# your
server ( It's the pid just before the one
# given
by twistd.pd )
os.system("kill -9 XXX") # Where XXX is the
pid of the aforementioned python
#
interpreter. kill -9 ensures that no cleanup occurs
# and the
notebook is not saved back to disk.
Hence, I can eliminate all user accounts and bring down the server.
When the server is brought back up, all of the user account
information
will be gone. Given the current design, I believe this exploit is
unavoidable (the server must have write permissions to those folders;
hence, it can delete the files).
Obviously, the biggest problem here is that the user has full access
to
a system terminal. A simple solution could be to re-bind the
os.system
function to None when the notebook is launched. Since I haven't dug
deeply enough into the notebook code yet, I don't know if this is
actually feasible (the notebook might use the os.system command.
Furthermore, since I'm new to Python, there might be a way to unload
and
reload the module that I don't know about. This would eliminate the
effect of the re-binding). Assuming that the re-binding trick works,
we'd probably want to use the same trick to black-list other commands
as
well.
Another alternative would be to allow the underlying operating system
to
have more control over the SAGE user accounts. Although SAGE allows
individuals to login on the front page, all "users" are actually just
the server user on the backend. In other words, this is really just
an
application-level user management scheme. In order to eliminate the
4th
exploit I described, you would need to map these to system users.
This
would imply that:
- The file deletions given above would only delete that user's
files
- The user would not have permission to bring down the server with
a kill -9
You would still need to be careful about how you set file and
executable
access for these individual users, but as you can see this alternative
already makes the server quite a bit safer. The only remaining
exploit
that I can think of is due to the power of the Python language.
Potentially, even if you got rid of programs such as scp (for file
transfer, if you recall), someone could write a simple file-transfer
program using Python and sockets. Once again, a black-list might be
able to address this issue, but another solution is probably
necessary.
Anyway, I've been typing this message long enough. I hope to hear
from
you soon about your thoughts on these issues.
-- TrixB4Kidz
P.S. You have a few hundred defunct sage processes running on your
system.
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
