Since both SSH and HTTPS use SSL, it is very hard for a corporate firewall to tell the difference
SSH (the protocol) doesn't use SSL (the protocol). One common SSH implementation (OpenSSH) uses the crypto libraries of one common SSL implmentation (OpenSSL).
It would be trivial for a corporate firewall to distinguish between HTTPS connections and SSH connections on port 443 (SSH connections all start with the the identifier "SSH-") but in practice most don't.
OpenSSH programmers taking the initiative to fix stupid problems like cross-platform compiling on a non-target CPU.
Like I said last time, none of the developers has a cross-compile environment so we can't test this. Also, like last time please either provide either a bug report (with contact address, so you can test a patch) or a tested patch (mail it to either the devel list or my address from my/. URL) so it can get fixed.
A slashdot post does not consistute a usable bug report. Even If I were to make the changes you're after I can't a) test it or b) get it to you so you can. I shudder to think what you'd have to do to a patch to get it past the lameness filter:-)
Yes, unfortunately, sometimes it takes longer than it should for things to be dealt with. Do you expect that refusing to do the little that was asked of you will improve this?
Is there a way to implement one time passwords with ssh?
Yes, there's several. Some SSH software has S/Key support (eg OpenSSH "./configure --with-skey"). The most current S/Key implementation seems to be the one in Wietse Venema's logdaemon package.
You can also do OTP through PAM or BSDauth if your platform supports those, eg pam_skey, pam_opie (OPIE: One-time Passwords In Everything)
Several systems have either S/Key or OPIE support natively (OPIE seems to be becoming the more popular of the two).
Actually this will have zero effect on the current crop of attacks. They make one password auth attempt then disconnect so MaxAuthTries never comes into play.
What it means is that a new copy of sshd is exec'ed for each connection after the master sshd fork()s to handle the connection. Previously, the forked sshd would just handle the whole session. It starts off as a literal copy of the address space of the parent and stays very similar throughout its life.
Now should there be some kind of vulnerability in sshd, an attacker can connect, get a new fork()ed copy of the master sshd and attempt to guess whatever they need to successfully exploit it. Should they guess wrong, their sshd will likely crash, but they can just connect, get another (identical) copy and try again.
Some systems (eg OpenBSD and PAX-based Linuxes like Adamantix) shuffle various things up (library offsets, stack location, ProPolice canaries, whatever) at exec() time. In the case of sshd, re-execing after the fork() means that instead of being able to linearly scan through the possible values needed to conduct the attack, the attacker has to guess the right ones for their current connection. Basically, instead of multiple shots at a stationary target, the attacker is now faced with an environment with lots of moving targets, all of which must be hit in order to conduct a successful attack. This should make it much harder to conduct the exploit.
This is indeed old news. An announcement was sent at the time to the mailing lists. A day or so ago, someone's broken email system remailed the message to the lists (check the wicked delay in the Received: headers). How it made to the front page of/. is another question...
If you have a serial console it's trivial to do a remote upgrade: download "bsd.rd" into/, then reboot and at the boot> prompt, type "boot/bsd.rd". You can then enter the installer and upgrade as normal. The filesets can be sourced from wherever is available (the network if it's up, a local directory if you have the disk space and download them in advance, or a CD if you have someone local to the machine to feed it).
I've done this many times (for values of "remote" equal to "downstairs" but as long as the console access is there then in theory it could have been anywhere).
If the upgrade goes pear-shaped for some reason then it might get tricky, however that's true of most remote upgrades (particularly if the machine doesn't have remote management hardware).
How? "./configure --target=foo" and "./configure --host=foo --target=bar" do not seem to enable cross compiling (at least without a cross compiler and build environment for the target?)
apply patches
What patches? None of the patches addressed the issue you brought up. I asked you to provide one and you refused.
If you had thoroughly read through the comments you would have seen that the same person who reported the openpty failure replied to you to say that the patches didn't work.
OK, fair enough. It looks like I misinterpretted what the poster said.
No. I don't have time to wait 4 years and 6 months for you
It wasn't that long, but yes, it would have been better to get to it sooner. Non-critical things that we can't test, or can't test easily tend to get delayed (in part, because of the reason above: a misunderstanding about whether or not it was actually fixed).
If you're genuinely interested in getting it fixed, how about a truce? If you provide a tested patch to configure.ac that fixes the openpty thing then I'll apply it. After that we can go back to flaming each other:-)
Someone already did reference this issue in the bug you referenced #321 [mindrot.org] yet the bug was labelled as "Resolved and Fixed" anyway. A simple test would have caught this issue.
What makes you think we have a cross-compile environment to test it on?
The reporters reported it worked for them (or that they had tested the wrong patch), so as far as I knew it worked ok.
As for submitting a patch: patches took 4 years to be accepted, and then 6 months for a release after that. What makes you think I have the time to deal with that?
So you have time to "to tediously hand-edit the configure script" every release and whine about it on/. but not submit a patch of your work so that you won't have to do it again?
... can be harder than writing it. When you're writing code or fixing a non-trivial bug, your understanding is built up as you work on it. When reviewing someone else's patch, you're starting cold and it can take a significant effort to comprehend it enough to even attempt to review it.
Brian Kernighan is widely quoted as saying: "Debugging is twice as hard as writing code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
When you're debugging, it involves rereading code you're already familiar with, so I suggest a corollary: reviewing someone else's code can be harder than writing it in the first place too.
That said, don't let it stop you from trying! Pick a patch from your favourite project and review it. Try to understand it. Look for places where it could be wrong.
Reviewing is a related but distinct skill from developing, and it can be improved with practice. A good reviewer is worth their weight in gold but it's often a thankless task (so let me take this chance to say a big thank you to markus and djm for putting up with my diffs:-).
And the unlabeled foot pedals hanging underneath of a car dashboard do what now?
Here in.au you learn what those do during the training that you receive before the written and practical tests that you must undertake before you are licenced to operate a motor vehicle. Driving without a valid license will attract a penalty and the license may be cancelled for cause.
Not that I'm advocating this model for computers, but it would solve a lot of problems. Imagine the test: "You have new mail: click here to download the latest update from Microsoft." *CLICK*. "You fail. Raise your hands above your head and step away from the computer."
When you're reading it, please note that the stratum and refid (the comment about ntptrace) things have been fixed in (in OpenBSD -current or portable snapshot).
Also I think the criticism about portability is not warranted. At the time that article was written OpenNTPD already supported Solaris (it was the 2nd target I did) and HP-UX support has since been added. I don't think it's valid to criticise a project that's only existed for a couple of months for "only" running on Linuxes, 4 *BSD's including OSX, and Solaris which covers the 3 main *nix families in use today (Linux, BSD, SysV). The split between OpenBSD and Portable is quite clean and the differences in the common code are small (~50 lines, the diff is in the Portable tarball).
The comment about clock disciplining is a fair point. Right now OpenBSD doesn't permit changing of tickadj at the default securelevel so another mechanism is needed in the kernel. In the mean time I've been experimenting with clock disciplining via Linux's adjtimex syscall (implemented with *zero* changes to the common code).
The comment about crypto depends on what your threat profile is. Relying on large crypto libraries means that you're less vulnerable to active attacks of the "make your clock wrong" type, possibly at the expense of being more vulnerable to attacks of the "0wnd ur b0x" type. Admittedly, in some cases (time sensitive authentications like Kerberos) the former may lead to the latter, but in many cases it can't.
Anyway, decide for yourself. You now have another option (which is why I embarked on -Portable in the first place).
When, exactly, were guided bombs used during WWII?
Well, the Germans had the Fritz-X, a radio-controlled guided bomb. It was used to sink a a battleship (Roma) and a cruiser (Spartan) and damaged several others. They apparently built around 1400 of them.
The Allies had Azon/Razon guided bombs, which apparently could be IR, radar, optically or wire guided. They were used for precision attacks (bridges and the like) but apparently weren't very successful.
It was June 2002, and here are the details including a description of the release process.
At the time of the original announcement it was specified that there was a way to mitigate the problem (Privilege Separation) and at least some of the criticism was because PrivSep didn't work on all platforms.
The patch was released early because the discoverer released the announcement early. I don't know if there were exploits available at that time.
Disclosure: I'm one of the OpenSSH developers, but I wasn't at the time, so I only know what was made public.
It might be more interesting to look for stolen Linux code in Unixware,
I'd suggest with the support for a very well known Linux fileystem in
the Linux compat addon product for UnixWare..
Oh, wait, you meant SCO code in the Linux kernel, right? Can't help you then.
Here is a company who in public says GPL is not legal. And these people are trying to use GPL against them.
SCO claiming that the GPL is not valid does not change the fact that the NMAP code is copyrighted, so in that case they are knowingly violating copyright law by shipping it.
Ironically, fixing exactly that problem is what the new PAM code was about. Instead of always assuming PAM is asking for a password, the new PAM code introduced in OpenSSH 3.7 uses SSH2's keyboard-interactive authentication (or TIS challenge-response for SSH1) to hold a proper "conversation" with the user before authenticating them.
A significant number of changes in 3.7 are removals (Kerberos 4, Kerberos5 in SSH1, AFS, Rhosts auth). Most people agree that simplicity is a wonderful goal... until that means the dropping (or not including) the feature they need or want. Then simplicity versus functionality versus security becomes a balancing act.
To put the size comment in perspective (this is 3.7p1 on Linux/x86): $ du -ks/usr/local/sbin/sshd/usr/local/bin/ssh 272/usr/local/sbin/sshd 224/usr/local/bin/ssh
Slashdot Mirror
It would be trivial for a corporate firewall to distinguish between HTTPS connections and SSH connections on port 443 (SSH connections all start with the the identifier "SSH-") but in practice most don't.
A slashdot post does not consistute a usable bug report. Even If I were to make the changes you're after I can't a) test it or b) get it to you so you can. I shudder to think what you'd have to do to a patch to get it past the lameness filter :-)
Yes, unfortunately, sometimes it takes longer than it should for things to be dealt with. Do you expect that refusing to do the little that was asked of you will improve this?
Yes, there's several. Some SSH software has S/Key support (eg OpenSSH "./configure --with-skey"). The most current S/Key implementation seems to be the one in Wietse Venema's logdaemon package.
You can also do OTP through PAM or BSDauth if your platform supports those, eg pam_skey, pam_opie (OPIE: One-time Passwords In Everything)
Several systems have either S/Key or OPIE support natively (OPIE seems to be becoming the more popular of the two).
Actually this will have zero effect on the current crop of attacks. They make one password auth attempt then disconnect so MaxAuthTries never comes into play.
What it means is that a new copy of sshd is exec'ed for each connection after the master sshd fork()s to handle the connection. Previously, the forked sshd would just handle the whole session. It starts off as a literal copy of the address space of the parent and stays very similar throughout its life.
Now should there be some kind of vulnerability in sshd, an attacker can connect, get a new fork()ed copy of the master sshd and attempt to guess whatever they need to successfully exploit it. Should they guess wrong, their sshd will likely crash, but they can just connect, get another (identical) copy and try again.
Some systems (eg OpenBSD and PAX-based Linuxes like Adamantix) shuffle various things up (library offsets, stack location, ProPolice canaries, whatever) at exec() time. In the case of sshd, re-execing after the fork() means that instead of being able to linearly scan through the possible values needed to conduct the attack, the attacker has to guess the right ones for their current connection. Basically, instead of multiple shots at a stationary target, the attacker is now faced with an environment with lots of moving targets, all of which must be hit in order to conduct a successful attack. This should make it much harder to conduct the exploit.
For a look at those moving targets, see Theo de Raadt's Exploit Mitigation Techniques paper.
This is indeed old news. An announcement was sent at the time to the mailing lists. A day or so ago, someone's broken email system remailed the message to the lists (check the wicked delay in the Received: headers). How it made to the front page of /. is another question...
I've done this many times (for values of "remote" equal to "downstairs" but as long as the console access is there then in theory it could have been anywhere).
If the upgrade goes pear-shaped for some reason then it might get tricky, however that's true of most remote upgrades (particularly if the machine doesn't have remote management hardware).
If you're genuinely interested in getting it fixed, how about a truce? If you provide a tested patch to configure.ac that fixes the openpty thing then I'll apply it. After that we can go back to flaming each other :-)
The reporters reported it worked for them (or that they had tested the wrong patch), so as far as I knew it worked ok.
So you have time to "to tediously hand-edit the configure script" every release and whine about it onWell, if you want it fixed then please open a bug at http://bugzilla.mindrot.org, and better yet, attach your patch.
That would be hpn-ssh. No, it's not in 4.0. Will it be included in future releases? Maybe, it needs to be looked at more closely.
FWIW I verified that the uploaded files are in fact correct.
It got a whole-digit bump because we ran out of minor digits and don't want double-digit minor version numbers (or hex :-).
Brian Kernighan is widely quoted as saying: "Debugging is twice as hard as writing code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
When you're debugging, it involves rereading code you're already familiar with, so I suggest a corollary: reviewing someone else's code can be harder than writing it in the first place too.
That said, don't let it stop you from trying! Pick a patch from your favourite project and review it. Try to understand it. Look for places where it could be wrong.
Reviewing is a related but distinct skill from developing, and it can be improved with practice. A good reviewer is worth their weight in gold but it's often a thankless task (so let me take this chance to say a big thank you to markus and djm for putting up with my diffs :-).
OpenSSH's -D (aka "DynamicForward") supports SOCKS5 as well (since the 3.7x release).
Here in .au you learn what those do during the training that you receive before the written and practical tests that you must undertake before you are licenced to operate a motor vehicle. Driving without a valid license will attract a penalty and the license may be cancelled for cause.
Not that I'm advocating this model for computers, but it would solve a lot of problems. Imagine the test: "You have new mail: click here to download the latest update from Microsoft." *CLICK*. "You fail. Raise your hands above your head and step away from the computer."
Also I think the criticism about portability is not warranted. At the time that article was written OpenNTPD already supported Solaris (it was the 2nd target I did) and HP-UX support has since been added. I don't think it's valid to criticise a project that's only existed for a couple of months for "only" running on Linuxes, 4 *BSD's including OSX, and Solaris which covers the 3 main *nix families in use today (Linux, BSD, SysV). The split between OpenBSD and Portable is quite clean and the differences in the common code are small (~50 lines, the diff is in the Portable tarball).
The comment about clock disciplining is a fair point. Right now OpenBSD doesn't permit changing of tickadj at the default securelevel so another mechanism is needed in the kernel. In the mean time I've been experimenting with clock disciplining via Linux's adjtimex syscall (implemented with *zero* changes to the common code).
The comment about crypto depends on what your threat profile is. Relying on large crypto libraries means that you're less vulnerable to active attacks of the "make your clock wrong" type, possibly at the expense of being more vulnerable to attacks of the "0wnd ur b0x" type. Admittedly, in some cases (time sensitive authentications like Kerberos) the former may lead to the latter, but in many cases it can't.
Anyway, decide for yourself. You now have another option (which is why I embarked on -Portable in the first place).
The Allies had Azon/Razon guided bombs, which apparently could be IR, radar, optically or wire guided. They were used for precision attacks (bridges and the like) but apparently weren't very successful.
At the time of the original announcement it was specified that there was a way to mitigate the problem (Privilege Separation) and at least some of the criticism was because PrivSep didn't work on all platforms.
The patch was released early because the discoverer released the announcement early. I don't know if there were exploits available at that time.
Disclosure: I'm one of the OpenSSH developers, but I wasn't at the time, so I only know what was made public.
That's easy: it was Christoph Hellwig and he said:
Oh, wait, you meant SCO code in the Linux kernel, right? Can't help you then.Ironically, fixing exactly that problem is what the new PAM code was about. Instead of always assuming PAM is asking for a password, the new PAM code introduced in OpenSSH 3.7 uses SSH2's keyboard-interactive authentication (or TIS challenge-response for SSH1) to hold a proper "conversation" with the user before authenticating them.
A significant number of changes in 3.7 are removals (Kerberos 4, Kerberos5 in SSH1, AFS, Rhosts auth). Most people agree that simplicity is a wonderful goal... until that means the dropping (or not including) the feature they need or want. Then simplicity versus functionality versus security becomes a balancing act.
/usr/local/sbin/sshd /usr/local/bin/ssh /usr/local/sbin/sshd /usr/local/bin/ssh
To put the size comment in perspective (this is 3.7p1 on Linux/x86):
$ du -ks
272
224