Slashdot Mirror
OpenSSH Gets Even More Suspicious
If you remotely administer any computers, or need to check your email over an untrusted network, odds are you're already familiar with the wonders of OpenSSH. Markus Friedl yesterday posted a release announcement for the newest version, OpenSSH 3.3. Privilege separation in OpenSSH is now enabled by default, another sign of the entire OpenBSD project's appropriate paranoia.
to bad that its not default on EVERY **nix
keanmarine.com
1st Official Slashdot to English Translator-matic
"Me and a bunch of people got drunk, thought we could code, submitted the idea and produced a fancy web page. It's now two years later and the project has no files to download and is STILL on Stage 1, Planning."
"I've been reading UNIX in a Nutshell for SVR4 and fuck knows what any of this flags stuff is about"
"I can install Red Hat from a bootable CD. The machine is not connected to a network and all I do all day is type ps, pwd and ls. I'm so l33t."
"My folks are rich enough to send me off for further education. I am now in an uber-elite crowd of know-it-alls and I am here to belittle you. Fear me."
"I've spent the last two years being subjected to biased slashdot propaganda. I couldn't hack into a properly configured windows system if my life depended on it."
"I've spent far too much time absorbing bullshit ideals from anarchists. The truth of the matter is, I just don't want to pay for anything whatsoever. Britney CDs should be free because I think that somehow the constitution protects my illegal copying and distribution under some freedom of speech law or fair use act. Even though I don't have to go out and buy luxury items, I'm gonna whinge and bitch anyway"
"I've only been using it for a week, and now my hardcore wannabe techno friends think I'm a guru. I now recommend it to everybody based upon what I've read at slashdot."
"Somebody please shoot me several times in the head. I am fucking clueless."
"I'm too fucking dense to realise that this has been going on for over 15 years already, and I've just finished reading 1984. Go figure."
One of the primary tenets of OpenBSD and NetBSD is security, correct? This is just another little bit of bytecode that improves security even more...
------- "From bored to fanboy in 3.8 asian girls" ----------
The way I read the headline, "OpenSSH Gets Even More Suspicious", it sounded like we're supposed to be more suspicious of OpenSSH.
:P
What has the world come to, where we can't even trust OpenSSH?
Oh, OpenSSH is more suspicious of its environment! That makes more sense!
Open Source software continues to impress me after so many years. This again proves, how much better software can be, if you remove management, lawyers, sales department etc. and make good programmers work together without short-term profit in mind.
Open Secure Shell? Is that like Passive Agression?
+1 for using left hand to press [Ctrl-C/V]
+1 for using right hand to move mouse
-3 for redundancy and trying to act clever.
Tournament Management Online &
You've heard of the recent apache bug. Apparently, the OpenBSD team is announcing it as a "possible remote crash".
Since a remote exploit already exists, shouldn't they detail the severity on their front page?
Nothing against the OpenBSD team... I believe they do excellent work, but heck, people, PLEASE patch up those systems! It's only a matter of days before someone is going to drop a new worm! This is horribly serious!
When I first started using linux, I was absolutely blown away by telnet, and the capabilities for remote administration.
Then came SSH... Not only is the grade of encryption absolute phenomenal, but the extras above and beyond remote shell's are astounding!
X Forwarding, SCP, FTPs, etc... they all rock! I can't remember the last time I coped a file over any protocol other than SSH's scp command. WinSCP has replaced puTTY as my favorite WIN32 application, and combined with puTTY and secure shells it's now wonder how I've managed to keep my home router/server up for 180 days w/o even having a monitor plugged into it!
Thanks OpenSSH team!
dmarien
Trust old telnet works fine, unless you are worried about people seeing your passwords, and everything you are doing. That is the point of ssh; it encrypts what you do, including passwords so it can not be seen by people on the same network segment. Telnet send your password and everything you do right over the wire without encoding it at all. A difficult password is just as important on telnet as in is on ssh because they can still be cracked either way.
By that measure, Win 95 beats pretty much all other OS's. And I take it that you still use Netscape 2.0?
Except telnet does zero encryption. It is a trivial matter to sniff passwords from an unencrypted link, and inserting data is not much harder. Changing passwords frequently is kind of pointless if you are setting your new password over an insecure link.
One-time passwords are better, but they are still vulnerable to TCP insertion attacks.
Yes, these things have been exploited in the wild. SSH exists for a reason.
If security problems in SSH itself worry you (and they should), privilidge-seperated ssh is the answer. By seperating the privilidged code from the code that talks to the client and defining a good interface between them, it limits the amount of stuff that can go wrong and the quantity of code that needs to be audited.
Other than the tty and authentication seperation, this doesn't sound a whole lot different than running sshd out of inetd. Or have I been smoking crack again without my knowledge?
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.
using namespace slashdot;
troll::post();
At my school we use SSH for accessing our UNIX accounts. I have always been impressed by the security offered by SSH. I just hope that the network administrators at my school decide to upgrade to OpenSSH.
...interesting if true.
I'm far from an expert on either system, but this seems similar to the system Keberos uses, 3rd party authentication... Am I totally misunderstanding the linked explanation?
Thanks
On related news, a basic security flaw in the SSH protocol was recently analyzed by Mihir Bellare et al.
The attack requires a carefully timed chosen-plaintext attack, but seems quite realistic in the setting of IP-over-SSH tunneling. Changes in the SSH protocol appear necessary.
Is there a tool that allows you to force the switch to forward ethernet frames so they can be sniffed without switch administrator access? Please offer some information on how this is done as I'd like to have a better understanding on how this works. What platforms does the tool run on, and on what switch platforms would it work against?
-Pat (a CCNP and MCSE)
Everyone should know better than to accept advice from random slashdot comments!
;)
Like this one?
There is also a tool to permit packet sniffing, see ettercap on Sourceforge.
Ettercap is actively being used by the "black hat" community, and has been found on compromised systems on switched LAN segments "in the wild".
I do not deploy Linux. Ever.
One issue with password cracking and sniffing is that it is critical to have a unique password for every site you have accounts at.
Under SSH, I can set up systems so that password logins only work on the physical console, not over the network. I can create a strong private key (passphrase protected) and install my public key on the remote servers, using the same key for many different servers without the security issues that come from using the same password across disparate sites.
I do not deploy Linux. Ever.
It is Timothy that we don't trust.
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.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Not bad. I'd go even further, and assert that almost every "Ask Slashdot" follows this template:
Q: I can do task T in Windows, but Linux seems to lack this feature/program/whatever. How do I do T in Linux?
A: Only a dumbass Windoze luser would want to do T.
Yes. But the hard part is getting into a position where you can even start to sniff.
Umm.. do you really think this is true? How much do you really trust the systems you're going through? I'll give you a real obvious example: if you're using a computer at work or at a lab at school, how hard do you think these systems are to compromise? If you didn't say "very easy" you overestimate the abilities of the people administrating these systems. I used to crack systems, and believe me, there were some very incompetant sysadmins out there (and still are these days). After the trivial matter of getting root, it was then a trivial matter of sniffing login/passwords and gaining access to even more systems. On a nice active system, I'd get dozens of new accounts every day.
Zoot!
yeah right
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
It seems to me that the entire GPL vs BSD debate is nothing more than a pastime for those with nothing better to do. Just think about it, a bunch of non programmers standing around bickering about licenses they'll never put anything out under anyway. Arm-chair quarterbacking for geeks.
As for actual developers, well there too the debate, or at least an ongoing never-ending squabble, is essentially pointless. Each programmer or team of programmers is going to choose and use the license they like best for the reasons they consider important. They have EVERY right to make this choice as they are the one's doing the work. Whether anyone else likes it or not is completely irrelevant.
Personally I like both licenses, but for different reasons. I see the GPL as a munition, a weapon. Putting high quality implementations of key tools and programs out under the GPL makes sure that the Microsofts of the world play nice by not being too greedy and/or abusing their customers. The downside to the GPL is that you're not going to obtain any financial gain from the products you release under it. There are rare exceptions such as RedHat, but then that company's product is a delivery system for GPL's software more than the software itself. Ultimately the value of GPL'd software is strategic, not directly economic. The GPL is most suitable for fundamental technologies that NEED to be kept absolutely open to ensure that incompatibilities don't creep in due to proprietary implementations. The BSD license is good because the code can be included in commercial programs. Now some people might start foaming at the mouth at the mere mention of commercial software. Of course these same people are usually in high school, college, or 35 and still living in their parent's basement.
Commercial software is what makes products that don't enjoy a wide following possible. Open Source is like socialism in a way. (Actually I don't think that my comparing Open Source to socialism was a very polite thing to do. Socialism is a system by which the abilities of one person are forcibly exploited to fulfill the needs of another. It and communism are but two points along the same continuum.) The base needs of the many are fulfilled, but what about the needs of the few? Does it make sense to try and organize a project to create an open source program to track oil deposits? How about an open source medical imaging system? There are some products for which there is a very small need in terms of how many people need the product. These same people are more often than not willing and able to pay good money to see that these products get created however. Also there is the question of expertise. Programmers are not experts on the best way to do everything possible with a computer. Imagine if someone tried to create an open source implementation of SPSS. Now what if I told you that such a project existed (PSPP) and that it hasn't gone ANYWHERE. The reason is that programmers are not statisticians. Their ability to verify the correctness of their own software's out put is next to nil.
At the end of the day both the GPL and BSD licenses have a useful function to perform. So does commerical software. Anyone who continuously argues about the role these three should play doesn't understand them in the first place.
Lee
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Do you have a link?
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Well, none of them ignore security, but OpenBSD is the most conscious. Quick and dirty comparo, a bit of a FAQ:
FreeBSD: Balls out performance on Intel.
OpenBSD: Most security conscious, most stared at source code.
NetBSD: Most portable. If it's got 32 bits and a MMU, it's got NetBSD.
There is some code sharing between these. I know the USB subsystem is shared among them (hell, it has CVS tags for NetBSD and FreeBSD) and probably some others. They talk amongst themselves too, and notify each other of problems.
No, you are out to lunch.
Sorry, but Telnet is a severe security hole.
Take a look at this link. The program Hunt can crash through a Telnet session and steal it. It is also possible to use a simililar attack on systems using SSH 1, which is why you should not use it.
Also, if you have ever heard of anything such as dsnifff you know that Telnet is practically useless in terms of security. Combine dsniff and hunt and you have one crappy method of defense. I don't care how strong your password is if I can:
1) Read it and capture it. (dsniff)
or
2) Simply steal the sesion, and thus have no need to type the password at all. (hunt)
Don't take anything in security for granted. For example I know of an admin who recently decided to implement backups to a remote NFS system, thus he opened up NFS, and thus portmap (port 111) to the world through his firewall. He still has no idea why this is bad, which explains why I will be completely reinstalling his servers in a few days.
You might not know why portmap is bad - but it is - you might also assume Telnet is ok. It is not. I have watched over 25 machines get compromised by Telnet, and I was the one who had to fix them. (I always get called in AFTER the fact - never before which I think is dumb.)
So, operate like OpenBSD - trust no one. Trust no protocol until you have a reason to trust it to some degree. And if you don't know why portmap / port 111 is bad, you may want to look that up at the same time.
Try to hack my 31337 firewall!
It depends on whether you already have a login somewhere. In which case you would simply be abusing the trust put in you by someone else.
/etc/passwd file, you didn't need to have a login to exploit this. There are many others, but that was a common one I saw everywhere. And the simple fact is people abuse trust and also people run trojan horses they receive in e-mail.
Remote attacks make it irrelevant whether you have a login or not. I'm not an expert on modern attacks, but I'm sure some people around here can talk about these things. I can give you an old example: YP/NIS used to allow anyone to download the
Besides, it wouldn't matter even they had. Because if you cannot trust public computers, then you can also not trust SSH on public computers.
That's true. There are many situations where you don't need to worry, but many situations where you should worry and take precautions. Here is another example: You take your laptop to a public facility (e.g. wireless network) where you connect to the network. You are going through a firewall to get to the Internet. You remote access your home computer through the Internet. A cracker has setup a sniffer on the firewall. SSH makes it difficult for the cracker to sniff anything useful from your session.
I trust foreign systems as much as you used to trust that your hacks would not be discovered.
Actually I sometimes waited for my hacks to be discovered and then laughed at the little traps the sysadmins left behind (yet they often didn't find everything and often left their systems unpatched). It was all in good fun and I tried to help 'em along sometimes (such as scare away other crackers with messages that their phone line has been traced). There were some sysadmins who reacted quick, and I actually helped them realize they needed to patch their system. I wasn't that great of a cracker, but I learned much from the experience, and appreciate the knowledge even more now that I am on the other side. Good times.
I actually don't worry that much most of the time. But there are times when you really should take some precautions. To automatically assume that there is no possibility of a threat is foolish.
Zoot!
You must be root to bind to any port <1024 as a form of "security" however this stupid rule has been the way in for most internet based security problems in the Unix world. Some systems (like Soalris) allow you to turn it off and that lets any process bind to any port but that has issues as well.
The correct solution is you let a process bind to any port >1024 and any port where the port number is in its group list. This means you put apache process owner in group 80 and 443 and then it can bind it its needed ports no matter who it runs as. Wiht the linux 2.0 kernal this required changing some of one line.
As far as the other problem of becoming someone else, there are no clean solutions to that but I think it would make sense to allow any process id 10 to become someone else. You also need to allow for some id's to give away files. The problem with this is that it intoduces magic numbers into the system which is bad.
Based in this, you could set up the ssh user as uid 1 in group 22 and it could bind to port 22 and then become any other user (or maybe any userid > 100). Bind would be running as user 53 with group 53 and have no special privs. The Apache user id would be in group 80 & 433 and its version of suexec would be uid 2 so it could change ownership to any user > 100 to run their cgis.
Q: Dear Bill I like that blue screen with the weird numbers and letter that I get every so often from windows. How do I get that with linux?
A: Install Windows it's the only way to get our patent pending BSO!
Blowfish is inherently insecure, ANY FILE LARGER THAN 1024KB YOU TRANSFER CAN BE DECRYPTED BY ANY 13 YEAR OLD WITH A POCKET CALCULATOR!
Hmmm... I tried that out, but it didn't work for me. I'm pretty sure the calculator is okay, do you think my 13 year old is faulty?
Sir, please locate a dictionary (ask mom for one) and look up sarcasm.
I too was online long before 95 was a twinkle in Bill's eye. The difference between you and I is not experience, but the ability to read.
The original poster refered to "cpu years running" as the measure of software. This is not the same as the number of years it has been around. VMS has been around a long time too, but hasn't racked up nearly as many cpu cycles as 95. I chose 95 as a rather arbitrarily example because it was so rampantly popular and widely used. It stuck around longer than any other single version of Windows.
Anyway, please find a sense of humor and report back when you do.
Many of us who transfer large amounts of data over the internet (TBytes worth) don't care about people decrypting our files. (To you my files would like random numbers anyway.)
We only really care about safegaurding the authentication process. In fact I would love to see a feature in scp where only the authentication is encrypted and all other data transfers are not.
Would you like to elaborate and become the first person with cryptanalysis which shows a weakness in Blowfish and thus enjoy the spoils of your elite mental power? You are about to knock Bruce of his pedestal and render his works suspect?
No? I thought not.
PS, moderators, the parent post is not "Insightful", it is one of either "Funny" or "Troll" depending on your mood and knowledge of Blowfish and typical Slashdot Anonymous Coward posts. I would lean towards Troll and moderate him down into the rest of the noise.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Jun 22 22:47:29 server sshd[711]: fatal: map(65536): Invalid argument
I got this on 2 machines, running RH6.2 and Slackware 7.1 (kernel 2.2.21 on both). Other two machines - Debian 3.0 & RH7.2, kernel 2.4.18, do work perfectly. WTF? I cannot find anything instructing in the source.
And it's done, for example in MicroBSD - http://www.microbsd.net
Helps spread the bits of "randomness" a little further. Why would you like it the other way around? Sounds insane.
Look at how a switch works. When you transmit a frame, it associates your MAC address with the port you're on. Next time a frame is sent to that MAC address, it sends it only to that port, becuase it knows that address is going to be found only on that port. If the switch does not know where a particular MAC address is to be found, it must send the frame to every port. Therein lies the weakness.
Switches tend to have finite sized MAC tables. If you overload them, they throw away older data in a least-recently-used manner. So the way to turn a switch into a hub is to send a non-stop stream of frames with random Ethernet source addresses. Make them small frames so you don't chew up all of the bandwidth of the switch, and don't send them too frequently (unfortunately, how frequently is too frequently is dependent on how big the switches table is). Address them to a known non-existent MAC address and make them a known unused Ethernet protocol. You will flood the switch's table and it will be forced to broadcast all frames. QED.
The problem is that ssh can change to any user it wants. That's the PROBLEM, that's the reason that bit was seperated out and away from the network traffic bit. It's not a solution.
Making it where the process id X (Where X is supposed to be sshd), can change to anyone else, is pretty much a negative solution to the problem, because now people can get root even after it's dropped privs. Not to mention now you cannot restart sshd if you need to, because it has to be pid X. And god help you when the kernel people come up with yet another 'fake' process that runs when the kernel starts, using no memory but taking up a pid.
And there is functionally no difference between being able to change to any user except root and being able to change to root. If you can change to the sysadmin's non-root account you can get root trivially by trojaning 'su', or, if he's very paranoid, by trojaning his shell.
If corporations are people, aren't stockholders guilty of slavery?
Capability-based rather than owner-based permissions.
That's not neccessarily the case anymore.
Dogma: Dead (mostly because your Karma ran it over)
Or you could bind to >1024, and redirect the packets from the lower port. (Not sure how to do this with Linux, but with ipfw on FBSD you can 'add ## fwd 127.1,8080 tcp from any to me 80').
Considering your later name-calling one would think you'd take the time to get a clue before spouting off.
First, not everyone uses switches. And even when they do, it is largely only at the local and remote points. intermediate hops happen at ROUTERS. Regardless, it is not all that difficult to sniff on a switched network either. Switches are not impervious to network attacks. Do some research.
And for that matter, there is encrypted telnet.
Encrypted telnet doesn't even come close to providing the features ssh does. Encrypted telnet is better that straight telnet, but not by much.
"No nation could preserve its freedom in the midst of continual warfare."
--James Madison
>I feel that C needs to be retired, much the same way that Fortran, Cobol and Perl have been
What makes you say Perl has been retired? From the number of scripts I write using it, the number of systems I see glued together by it and the sheer volume of Websites using it, I would say it is anything but a retired language.