How do you decide when to end a penetration study? For ex. when you hire a team that is discovering the loopholes in the system, when do they decide on not spending any more time on that because they're sure they have discovered all loopholes? In other words, is the duration of penetration study a part of the contract or the hacking team decides when to end it based on their experience with the system.
The duration of a penetration study is part of the contract. It may be a time limit, or the study may end when a specific event (such as sensitive data being obtained) occurs. At no point do testers think they have found all flaws. The study is an attempt to draw conclusions about the general security of the system, and where efforts to find and fix security problems should be concentrated.
How secure is the Kerberos protocol used by this University? I've read in a magazine that in Kerberos, the keys entered by the user are cached locally. This means in a diskless enviroment, this /tmp directory is stored on a file server and the keys travel across the network. Our data can then be accessed by another party! I've read that the Leighton-Micali scheme is more robust so shouldn't this protocol be preferred over Kerberos? What are some of the advantages of Kerberos that makes this security protocol sufficent for the protection of student's data?
Kerberos uses a temporary file to store tickets, not cryptographic keys. (A ticket is a token that contains a process identity and is enciphered with the secret key of the server. For more details, see the handout Two Protocols.) The cryptographic keys are stored in memory. On a multiu-user system, these are still potentially visible to processes with root privileges, but it's hard to locate the exact keys in memory. Also, keys are never sent over the network in the clear.
I don't know of software as mature as Kerberos that implements Leighton-Micali. That's a major consideration in the use of cryptosystems: the systems that implement them, how mature and how well integrated those systems are. Kerberos has been around 15 years (the theory 25 years), and the protocol is widely used and implemented. That's not true for Leighton-Micali, at least now.
Once a security hole/threat has been discovered, and a patch or workaround produced, how good are software manufacturers about avoiding those security holes in future software packages? Do the same security problems continue to arise, even though they may be avoidable?
This is a sore point among many people. Some vendors are very responsive (Sun, the free UNIX-like systems like FreeBSD and Linux, and Microsoft). Others say it will be fixed in the next release. The problem is that many of the problems arise from a lack of coherent design, leading to an attempt to "patch" things up. And yes, the same security problems continue to arise, even when they are avoidable. If you have any ideas on how to stop this, we'd be very interested. Nothing has seemed to work in the past 25 years!
On a system where memory is shared, does each user get a certain amount or is there no limit? Could a user fork a process a bunch of times where the only thing that the process does is malloc a bunch of pointers and fork more processes to eat up the system resources and slow things down for other users?
This varies from system to system. On some systems, the answer is that filling up the process table using fork(2)s would cause it to crash. On others, the system reserves a couple of slots so a root process can terminate the others. On still other systems, each user has a quota of processes, memory, and disk space that prevents the problems you describe.
This is more of an ethical question. In class today (tues), you mentioned the gaming issue where you found using the game's feature of spawning a shell gave you root access. If your school's policy said explicitly that no one besides privileged sys admin's shoudl have root access, would you be held responsible? even if you reported it right away? (this goes back to the girl finding a hole, exploiting, and reporting). ie, if you find a hole "by accident", does the intent matter?
This varies, but the general is that discovering a security hole is fine. Exploiting it is not. We found the problem purely by accident (yep, I was one of the ones who found it) and when we realized what was going on, we immediately exited the shell and reported the problem. Folks were amused, as we were considered "trusted" (heck, we were grad student system administrators and system programmers, and we all had the root password).
Had it been an ordinary student, I suspect the test would be: when you figured out you were root, did you exit immediately and report it? If yes, I can't imagine anyone sane taking action against the reporter. If no, it's more of a gray area.
I am using RESnet at home. Recently, I have received an email from school housing saying that they will cut down the bandwidth with we access off campus sites. The reason they are doing this because they have "MONITORED" that most people are not using it to download mp3, games and etc.
Doesn't this violated our personal privacy?
By "not using it" do you mean "using it"? I cannot imagine the University requiring you to download MP3, games, and such ... (sorry -- couldn't resist).
I suspect what is happening is this: the bandwidth usage has climbed to the point that the traffic interferes with people using the network. The RESnet administrators and network administrators began to monitor the traffic to figure out what was going on. Typically, this involves looking at the headers of the packets only. If the header has napster port numbers, it's a good guess that MP3 is being used. And so forth. Once they discovered the main protocols in use, they have three options: restrict use of the protocols, or give everyone a certain maximum bandwidth for whatever use you want to put it to, or simply give RESnet a fixed maximum bandwidth. From your question, I don't know which of thse they chose.
I don't think it violates your personal privacy because they couldn't care less what you're listening to, and in fact from your description I doubt they could say, "Well, Matt Bishop listened to Eubie Blake last night and to Scott Joplin tonight ..." I think they were just looking at headers. I don't think that's any different than monitoring water usage to find the big wasters. They don't ask what you do with the water; they just say that you're using 100 times as much as everyone else, and we're in a drought, so we're going to restrict you to what everyone else is using. If you need more, you need to make a case for it.
Office: 3059 Engineering Unit II Phone: +1 (530) 752-8060
Fax: +1 (530) 752-4767
|Copyright Matt Bishop, 2000. All federal and state copyrights reserved for all original material presented in this course through any medium, including lecture or print.