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.
Previously any corruption in the sshd could lead to an immediate remote root compromise if it happened before authentication, and to local root compromise if it happend after authentication. Privilege Separation will make such compromise very difficult if not impossible.
Open Secure Shell? Is that like Passive Agression?
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!
That was a superb troll. Well done!
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
dude you are so gonna get flamed for that
I'm a fan of anything that promises to reduce the susceptibility of Unix/Unix workalikes to worms.
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.
[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]
When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.
Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.
FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.
It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.
So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.
Discussion
I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.
From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.
There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.
Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.
Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?
Shouts
To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.
To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.
To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.
To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.
To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.
Future
I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.
However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.
You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.
= Mike
--
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?
use tera term dude
Wouldn't you rather get an e-mail sent to you when a patch is out instead of constantly checking the OpenBSD homepage for patch info?
BTW, the exploit was published after the patch, that's why it's listed as "possible"
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.
keep m coming :]
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)
Blowfish is inherently insecure, ANY FILE LARGER THAN 1024KB YOU TRANSFER CAN BE DECRYPTED BY ANY 13 YEAR OLD WITH A POCKET CALCULATOR!
Everyone should know better than to accept advice from random slashdot comments!
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.
How many passwords have you sniffed? And ho much data have you inserted?
Or are you just a blowhard souting drivel you've seen elsewhere.
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
Dude, it's easy to do. Get over it.
Many people around Slashdot are fully capable of both sniffing passwords and data insertion.
That shit was fucking funny!!!
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.
Except for the networking test part, very well done!
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, but I doubt if much Internet traffic is routed through a 13-year-old's bedroom.
yeah right
I came to the datacenter drunk with a fake ID, don't you want to be just like me?
Good thing everyone uses switches. And for that matter, there is encrypted telnet. You people are truly retarded.
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.
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.
I trust most systems very much. I routinely connect to other computers without knowing whether there is a bug in the software that I am using that might let the other computer cause harm. The reverse happens as well.
That is not to say that I don't use SSH (or some such) if it is available. However lab computers or other publicly accessible computers may not have SSH installed. 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.
I trust foreign systems as much as you used to trust that your hacks would not be discovered.
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.
Just by using OpenSSH you automatically attract the attention of certain federal authorities who assume you're up to something that requires them to poke their nose into whatever you're doing via OpenSSH.
By that measure, Win 95 beats pretty much all other OS's
I'm not sure what you are thinking if you think a 7 year old OS can beat all the other 20+ year old OSes out there. I mean you could even say DOS beats win95. You don't sound very experienced if you think Win95 is old. I had been online for 10 years before it was released.
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!
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.
NIGGAH PLEASE!
got kfc?
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
The 13 year old must be teh 31337 5|<r1p7 |<1dd13 to be successful.<br>
And 5|<r1p7 |<1dd135 can be kept off your computer by washing your ears twice a day.
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)
And it's done, for example in MicroBSD - http://www.microbsd.net
Actually it's done here: http://www.lucq.org/openbsd/patches.php (about halfway down the page), from where MicroBSD obtained the code...
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').
My old but faithful TRS-80 still runs... I still occasionally power it up and play a few games of 'Galaxy Invasion' (aka Galaxian) on it. Vintage 1979, when I got the machine...
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
It seems that while the lastest security hole found in OpenSSH is not fixed, the ISS and OpenBSD people try to keep the details of the problem for themselves.
This method is maybe good for a short time, but I hope this will be fixed soon.
>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.