Hey again. I actually got a similar reply from William earlier today that I was going to append to this message (this post took quite some time to appear on google groups for whatever reason). The particular attack that I described is preventable, but the fact that the users have full access to a shell creates the potential for large security vulnerabilities. In particular, what about the other systems on your network? You've just given everyone access to your system behind your firewall. With this, I could easily write a script that punches a hole through your firewall and creates a pipe to one of your blocked ports.
What I'm more concerned about is the fact that this model opens the rest of your network up. I mean, the attacker is behind the firewall on a computer that is part of a campus's internal network. One could build a crawler in Python that discovers the hidden network topology, port maps all of the systems, and sends the results back to their system via a raw socket or scp. So even if your server is rock-solid, the attacker has still learned about several other potential entry points into your network. Hence, the SAGE server could simply serve as a stepping stone into a larger-scale attack on the network. On Oct 16, 6:02 pm, "Timothy Clemans" <[EMAIL PROTECTED]> wrote: > 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 athttps://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/ -~----------~----~----~----~------~----~------~--~---
