For those of us without much experience in the encryption and networking fields, anyone mind explaining exactly what this does? I read the page but I'm not sure I understand exactly what's going on.
This isn't a change to the communications protocols or any of the encryption - it's a change to the Unix implementation of the server to make it much less likely that any bugs can let someone break in. (Initially this works for OpenBSD, should be easy to port to other BSD implementations, probably to Linux and Solaris, maybe to WinNT but maybe not.) The basic way that a communications server like this works is
A process sits around listening to the well-known TCP port for connection requests. The process needs to be privileged for two reasons
The port is a system resource so only the system should be able to control it
When a user logs in (on Unix), their connection needs to operate with the permissions of that user, so the server needs to be root so it can start a session as any user who logs in (as opposed to a Web Server, which usually only needs access to publicly readable files.
When a request comes in, it hands it to a subroutine that handles requests for the server to do different functions, including authentication.
For some services, such as SSH and FTP, the server may set up multiple connections for things like transferring files, etc.You can write a server like this as one big single-threaded process, or as one big process with multiple threads if your operating system and programming environment support it, but it's more common, especially on Unix, for the main process to spin off several child processes to do the work and go back to listening for new incoming requests. In this case, it spins of one process to handle the control channel communications and that process spins off other processes to handle specific tasks like file transfers, after checking that the connection and the request are authenticated. In a simple-minded implementation, the control channel process runs as root, and any task channel processes start off as root, and maybe change their privileges to an individual user's privileges if they need to (for instance if you're using SSH to log in to a remote system.)
The problem with this is that if there are any bugs that let a remote connection send messages with unexpected data in ways that break or take over the server process, the server is running as root so it can do anything it wants, however evil or dangerous (or if it's a minor bug that doesn't lead to a complete takeover, it may still be able to burn critical resources and stall the system or do some other denial of service attack.) Two popular kinds of attacks are sending a message that overflows a field (the result of bad protection in the C language combined with careless programming), or sending a message that asks the process to do something that the programmer didn't expect and protect against, such as setting permissions on a system file or making a user's program privileged, so that it can be exploited later, either by another communication from the attacker or by routine activities by the system or the user.
What the new OpenSSH implementation does is takes the bottom two server processes (the control channel server and the task servers) and splits each of them into two parts that communicate with each other. One part of each processes is a master, that keeps running privileged if it needs to, and the other is a slave process that runs as a non-privileged user (either the user who's requesting the service, for tasks like logins, or as the "nobody" user) and does most of the actual work, passing messages back and forth to the master process to communicate about status and request anything that still requires privileges. This gives you a bunch of security advantages:
Each part of the system is smaller, with fewer functions to perform and well-defined interfaces to other parts, so you can do a better job of checking for bugs and each part can validate incoming messages before doing anything.
The parts of the system that need to be privileged aren't communicating directly with the remote user, only with the slave processes, so they have a much smaller set of messages to validate.
If there's some bug in the system that lets a remote attacker take over one of the control or task processes by sending an craftily designed message, the bug is in the non-privileged slave process, which doesn't run as root, can't do as much damage, and has a limited set of messages that the master process will accept from it.
The rest of it is basically detail about which functions they separated into which programs, how they made sure that each piece has enough capabilities to do the job without giving it too much power that could be exploited by an attacker, and some stuff about how they validated the pieces. It's adding more complexity to the total system, but each piece is more limited in function, and the security-critical pieces are much easier to validate against bugs and malicious input.
Uh...? (Score:4, Interesting)
What it does - Program, not Protocol Security (Score:5, Informative)
When a request comes in, it hands it to a subroutine that handles requests for the server to do different functions, including authentication.
For some services, such as SSH and FTP, the server may set up multiple connections for things like transferring files, etc.You can write a server like this as one big single-threaded process, or as one big process with multiple threads if your operating system and programming environment support it, but it's more common, especially on Unix, for the main process to spin off several child processes to do the work and go back to listening for new incoming requests. In this case, it spins of one process to handle the control channel communications and that process spins off other processes to handle specific tasks like file transfers, after checking that the connection and the request are authenticated. In a simple-minded implementation, the control channel process runs as root, and any task channel processes start off as root, and maybe change their privileges to an individual user's privileges if they need to (for instance if you're using SSH to log in to a remote system.)
The problem with this is that if there are any bugs that let a remote connection send messages with unexpected data in ways that break or take over the server process, the server is running as root so it can do anything it wants, however evil or dangerous (or if it's a minor bug that doesn't lead to a complete takeover, it may still be able to burn critical resources and stall the system or do some other denial of service attack.) Two popular kinds of attacks are sending a message that overflows a field (the result of bad protection in the C language combined with careless programming), or sending a message that asks the process to do something that the programmer didn't expect and protect against, such as setting permissions on a system file or making a user's program privileged, so that it can be exploited later, either by another communication from the attacker or by routine activities by the system or the user.
What the new OpenSSH implementation does is takes the bottom two server processes (the control channel server and the task servers) and splits each of them into two parts that communicate with each other. One part of each processes is a master, that keeps running privileged if it needs to, and the other is a slave process that runs as a non-privileged user (either the user who's requesting the service, for tasks like logins, or as the "nobody" user) and does most of the actual work, passing messages back and forth to the master process to communicate about status and request anything that still requires privileges. This gives you a bunch of security advantages:
The rest of it is basically detail about which functions they separated into which programs, how they made sure that each piece has enough capabilities to do the job without giving it too much power that could be exploited by an attacker, and some stuff about how they validated the pieces. It's adding more complexity to the total system, but each piece is more limited in function, and the security-critical pieces are much easier to validate against bugs and malicious input.
short summary --- Re:What it does - Program, not P (Score:1)