Hi, The public notebook servers on sage.math.washington.edu are jailed (http://sagemath.org/doc/html/inst/node10.html). Also there is a pool of 30 unix users that are used to evaluate worksheet code. That protects the main notebook system from a random user. Ulimit is also used.
If I remember right William welcomes people to try to vandalize the notebook server at https://sage.math.washington.edu:8102 ------------------- How William runs the public notebooks from William himself: (1) have a file that starts the notebook by running a .py file: [EMAIL PROTECTED]:~/nb1$ more start_notebook cd /home/server2/nb1 sage notebook.py > nohup.out & (2) The actual .py file: [EMAIL PROTECTED]:~/nb1$ more notebook.py from sage.all import * server_pool=['[EMAIL PROTECTED] -p 7000'%n for n in range(1,31)] notebook(port=8103, accounts=True, address='sage.math.washington.edu', secure=True, server_pool = server_pool, ulimit='-v 2000000') On 10/16/07, TrixB4Kidz <[EMAIL PROTECTED]> wrote: > > 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/ -~----------~----~----~----~------~----~------~--~---
