Re: [Full-Disclosure] SSH Exploit Request
On Sat, 15 Nov 2003, Bryan Allen wrote: On Nov 14, 2003, at 9:10 PM, [EMAIL PROTECTED] wrote: You install a borked build of ssh (shared lib dependencies are FUN), restart it, your session goes bye-bye, and you can't get back in to fix the runaway sshd that's chewing all the resources Restarting sshd does not kill running ssh sessions, as they're all forked and in memory. But, there can be other reasons a connection get hosed, and this was what was being refered to here. Thanks, Ron ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Sun, 16 Nov 2003 08:30:03 EST, Vladimir Parkhaev said: Of course not, but I personally prefer to take a chance (and responsibility) for impacting a prod server with gone-wild-ssh-update over being 0wned. `As do I. Maybe I've just been reading comp.risks for too many years, but what I objected to was the it's *perfectly* safe... attitude that some were projecting. The older readers on this list probably remember a movie trailer with the line and nothing can possibly go wrong.. go wrong.. go wrong.. go wrong pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] SSH Exploit Request
`As do I. Maybe I've just been reading comp.risks for too many years, but what I objected to was the it's *perfectly* safe... attitude that some were projecting. The older readers on this list probably remember a movie trailer with the line and nothing can possibly go wrong.. go wrong.. go wrong.. go wrong I think it was around version 3.0.1 where the bright folks working on the ssh project released a version where you could log in as any user by providing any password of two characters in length...which was either extremely stupid or extremely intentional. Don't let anyone ever make you feel paranoid. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Friday 14 November 2003 21:27, madsaxon wrote:
At 10:13 PM 11/14/2003 -0600, Paul Schmehl wrote:
Nope. But I sure do in a lot of other unixes. Wasn't
thinking of Solaris at the time. Sorry.
'shutdown -g -i[n] -y' is the System V command
'shutdown now' is BSD.
IIRC, SunOS used the BSD version, but starting with
SunOS 5.5 they switched to System V shutdown.
Solaris ('til v 7, at least) keeps a Bekeley-syntax shutdown in
/usr/ucb/bin/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/tcXqJi2cv3XsiSARAvaCAKCJVQfH92Q2lwIhm6sjm6HQtFjvXwCglCIH
a8C1+vxykKXQKHVc1H+ee7I=
=CZ0M
-END PGP SIGNATURE-
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
At 10:21 PM 11/14/2003 -0800, Jeremiah Cornelius wrote:
Solaris ('til v 7, at least) keeps a Bekeley-syntax shutdown in
/usr/ucb/bin/
Looks like it's still there in 8, also.
m5x
___
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Nov 14, 2003, at 9:10 PM, [EMAIL PROTECTED] wrote: You install a borked build of ssh (shared lib dependencies are FUN), restart it, your session goes bye-bye, and you can't get back in to fix the runaway sshd that's chewing all the resources Restarting sshd does not kill running ssh sessions, as they're all forked and in memory. -- bda Cyberpunk is dead. Long live cyberpunk. http://mirrorshades.org ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Fri, 14 Nov 2003 22:21:30 PST, Jeremiah Cornelius said:
Solaris ('til v 7, at least) keeps a Bekeley-syntax shutdown in
/usr/ucb/bin/
Remember what I said about what happens if you set your root login shell to be
/usr/local/bin/glitzy-shell?. Well, I've got a nice story about Solaris and
/usr/ucb.
I'm one of the gang of inindicted co-conspirators who are to blame for the
Center for Internet Security benchmarks. One of the things the Solaris
benchmark includes is cut-and-paste code to implement each recommendation. So
anyhow, we get feedback from one site, complaining that some of their
configuration files now have literal backslash tee backslash tee backslash tee
where there should be a sequence of 3 tabs.
I finally tracked that one down to the fact that the Solaris shell 'echo'
builtin actually *checks* $PATH to see if /usr/ucb is in it, and if so, if it's
before or after /usr/bin, and then emulates a SysV or BSD echo. And the BSD
echo doesn't handle escape sequences the same way. Whoops. We got to go
through and replace all the echo's with printf's.
Yes, a bug in our code. However, one totally unexpected, even by any of the
large number of Solaris experts, and it didn't crop up on the first several
hundred or thousand boxes it was tested on
And *that* sort of bug is the one that answers the question How could patching
XYZ *possibly* take down a server?.
pgp0.pgp
Description: PGP signature
Re: [Full-Disclosure] SSH Exploit Request
On Sat, 15 Nov 2003 07:01:09 EST, Bryan Allen [EMAIL PROTECTED] said: Restarting sshd does not kill running ssh sessions, as they're all forked and in memory. What? You never said Shit, I should have checked if I can su/login/ssh/whatever *after* you closed your last root window? :) And yes, *your* ssh can still go away if something else does a runaway and runs the system out of swap space. Although many vendors have an out-of-memory handler that does the best thing most of the time, none of them do the best thing ALL the time. And even if it doesn't, the system may be simply thrashing itself to death but *not* actually killing anything.. What use is an open SSH window, Mr Anderson, if you have no character echo? I'm surprised that on a security list, so many people are so ready to take a very unlikely to happen condition and label it as a *cant* happen. Come on guys - that sort of assumption is what often *creates* security holes: Nobody could POSSIBLY unlink this file and replace it with a symlink between when we stat() it and when we open() it. Things rarely go wrong when everything is at nominal. Things usually go wrong in a failure cascade - when one sysadmin is installing software during a 2AM test window and he's tired and cranky because instead of getting some sleep, he had a big fight with his SO, and the software was built by another sysadmin who didn't get to actually finish those last few tests before she tripped and broke her ankle, while it's being installed onto a disk that's flaky and not always reporting write errors (and yes, I've actually seen all three of those happen in shops I was working in at the time, fortunately not all at once. On the flip side, each of the three was by itself enough to cause a failure) pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] SSH Exploit Request
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): And yes, *your* ssh can still go away if something else does a runaway and runs the system out of swap space. Although many vendors have an out-of-memory handler that does the best thing most of the time, none of them do the best thing ALL the time. And even if it doesn't, the system may be simply thrashing itself to death but *not* actually killing anything.. more end-of-the-world-scenarios deleted Valdis, you forgot to mention some other cases in which upgrading SSH can take down a production server. Those include: 1. Upgarding SSH while having sex. 2. Droping a server in a bathtub full of hot water right after the upgrade. 3. Aliasing 'sshd' to '\rm -rf /' ans typing sshd. and many many more... The fact is, upgrading sshd (not XYZ!) does not require reboot and does not affect any other processes that server runs. If you don't beleive me, just... try it :) -- .signature: No such file or directory ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Sat, 15 Nov 2003 20:56:51 EST, Vladimir Parkhaev said: The fact is, upgrading sshd (not XYZ!) does not require reboot Normally, yes. and does not affect any other processes that server runs. Again, normally yes. But if you believe it's *impossible* for a run-away process to not affect other processes, I suggest you go read up on fork bombs, the numerous ways that various OOM-killers in the Linux kernel have proven deficient, and a lot of other related issues. If you don't believe me, just... try it :) I've *been* trying it since it was ssh.com's version 1.2.verysmallN or so. Has worked reasonably every time, except for the one time I built it on an IRIX 6.5.N and installed it on 6.5.M, where MN. It promptly ran afoul of an API change, went runaway, and earned me a trip to the data center to unsnarl things at the console. (I also hit a similar problem when the sshd was linked on an AIX system with the 4.3.3.75 version of libc, but tried to run on a pre-.75 version, but *that* one promptly died a quick and horrible death without impacting anything else). estimates number of SSH versions times number of machines, and gets at least 4 digits So we've got some 99.98% reliability in installing sshd without disruption. But 99.98 isn't 100 unless you work at Intel. Any my point is that anybody who's running a production system who is installing *ANYTHING* with the attitude this can't *possibly* fail is looking for a VERY rude awakening when it *does* fail. So tell me - do you trust the installs enough to just do it and logout without bothering trying to ssh in to make sure it works first? ;) pgp0.pgp Description: PGP signature
RE: [Full-Disclosure] SSH Exploit Request
On Thu, 2003-11-13 at 09:08, Robert Davies wrote: I am quite bothered out the ass by well paid admins that are too damn lazy to spend the few minutes it takes to repair a flawed service. Either start doing your job, or get the hell out of the way for those of us that want to do the job required properly! life must be wonderful for you. from your post, you clearly don't report to anybody or have anyone to which you must explain your actions if they inadvertently bring down a prod system. i'm sure no one on this list has ever had that happen. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Quoting g0d ([EMAIL PROTECTED]): life must be wonderful for you. from your post, you clearly don't report to anybody or have anyone to which you must explain your actions if they inadvertently bring down a prod system. i'm sure no one on this list has ever had that happen. Hate to stick my nose in ths thread... but how updating SSH daemon brings down a production system? -- .signature: No such file or directory ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
i do to... but just for the sake of argument say his corp change control process states that after a new service is installed (or updated) the system must be rebooted to make sure that the boot process was not damaged. -KF Hate to stick my nose in ths thread... but how updating SSH daemon brings down a production system? ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Fri, 14 Nov 2003 20:00:59 EST, Vladimir Parkhaev said: Hate to stick my nose in ths thread... but how updating SSH daemon brings down a production system? Well, *that* particular one is unlikely. But I've seen it happen. You install a borked build of ssh (shared lib dependencies are FUN), restart it, your session goes bye-bye, and you can't get back in to fix the runaway sshd that's chewing all the resources The more generic point is that in larger shops, you usually need to get *everything* planned and OK'ed in advance, including backout plans. And even then things go wrong. I'm sure I'm not the only sysadmin who's SSH'ed in to an ill box, decided a reboot was needed, and typed 'shutdown -i6 -g0 -y' (runlevel 6 to reboot, zero seconds grace, and don't prompt me), and instead realized 7 seconds later that what the other end *received* was '-i0 -g6 -y' (poweroff with 6 seconds warning), and made a bad situation worse. What *I*'d like to know is how the transposition gremlins know that it's 2AM on a major holiday, or a snowstorm, or other reason that the NOC is running lights-out and nobody's there to push the button to power it back on... pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] SSH Exploit Request
--On Friday, November 14, 2003 21:10:04 -0500 [EMAIL PROTECTED] wrote: I'm sure I'm not the only sysadmin who's SSH'ed in to an ill box, decided a reboot was needed, and typed 'shutdown -i6 -g0 -y' (runlevel 6 to reboot, zero seconds grace, and don't prompt me), and instead realized 7 seconds later that what the other end *received* was '-i0 -g6 -y' (poweroff with 6 seconds warning), and made a bad situation worse. Just curiouswhy wouldn't you use 'shutdown -r now'? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Just curiouswhy wouldn't you use 'shutdown -r now'? shutdown on a sun box. (from the manpage) NAME shutdown - shut down system, change system state SYNOPSIS /usr/sbin/shutdown [ -y ] [ -g grace-period ] [ -i init- state ] [ message ] -Peter -- Peter Moody [EMAIL PROTECTED] Information Security Administrator 831/459.5409 Communications and Technology Services. UC, Santa Cruz. http://security.ucsc.edu/pgp/peter.moody.pub :wq signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] SSH Exploit Request
On Fri, 14 Nov 2003 20:36:59 CST, Paul Schmehl [EMAIL PROTECTED] said: Just curiouswhy wouldn't you use 'shutdown -r now'? % uname -rsv IRIX64 6.5 10151453 % man shutdown shutdown(1M) shutdown(1M) NAME shutdown - shut down system, change system state SYNOPSIS cd /; /etc/shutdown [ -y ] [ -ggrace_period [ -iinit_state ] [ -p ] OK.. Let's check another box... % uname -rsv SunOS 5.8 Generic_108528-22 % man shutdown Reformatting page. Please Wait... done Maintenance Commands shutdown(1M) NAME shutdown - shut down system, change system state SYNOPSIS /usr/sbin/shutdown [ -y ] [ -g grace-period ] [ -i init- state ] [ message ] You see a -r in either of those? I don't. pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] SSH Exploit Request
On Nov 14, 2003, at 8:36 PM, Paul Schmehl wrote: --On Friday, November 14, 2003 21:10:04 -0500 [EMAIL PROTECTED] wrote: I'm sure I'm not the only sysadmin who's SSH'ed in to an ill box, decided a reboot was needed, and typed 'shutdown -i6 -g0 -y' (runlevel 6 to reboot, zero seconds grace, and don't prompt me), and instead realized 7 seconds later that what the other end *received* was '-i0 -g6 -y' (poweroff with 6 seconds warning), and made a bad situation worse. Just curiouswhy wouldn't you use 'shutdown -r now'? Because that requires a non convoluted OS such as BSD. None of that -thousand -switches -from -hell -SYSV -stuff. :-) Chris Watson M.M. Bestor G. Brown #433 Wichita, KS AIM: BSDUNIX44 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
--On Friday, November 14, 2003 22:46:31 -0500 [EMAIL PROTECTED] wrote: On Fri, 14 Nov 2003 20:36:59 CST, Paul Schmehl [EMAIL PROTECTED] said: Just curiouswhy wouldn't you use 'shutdown -r now'? % uname -rsv IRIX64 6.5 10151453 % man shutdown shutdown(1M) shutdown(1M) NAME shutdown - shut down system, change system state SYNOPSIS cd /; /etc/shutdown [ -y ] [ -ggrace_period [ -iinit_state ] [ -p ] OK.. Let's check another box... % uname -rsv SunOS 5.8 Generic_108528-22 % man shutdown Reformatting page. Please Wait... done Maintenance Commands shutdown(1M) NAME shutdown - shut down system, change system state SYNOPSIS /usr/sbin/shutdown [ -y ] [ -g grace-period ] [ -i init- state ] [ message ] You see a -r in either of those? I don't. Nope. But I sure do in a lot of other unixes. Wasn't thinking of Solaris at the time. Sorry. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 fastboot ??? :) Used to have that on AIX. Probably SYSV standard, tho I'm not sure. []s On Fri, Nov 14, 2003 at 10:46:31PM -0500, [EMAIL PROTECTED] wrote: % uname -rsv IRIX64 6.5 10151453 % uname -rsv SunOS 5.8 Generic_108528-22 - -- Rodrigo Barbosa [EMAIL PROTECTED] Quid quid Latine dictum sit, altum viditur Be excellent to each other ... - Bill Ted (Wyld Stallyns) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/takipdyWzQ5b5ckRAgC4AJ94nT2W5Iypi8HL/autX1NHDrjtTwCeNbBn a8wSJBk2Yu5GmUl8N5EAg+Q= =R89V -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Sat, 15 Nov 2003 02:18:42 -0200, Rodrigo Barbosa said: fastboot ??? :) Yes, I know all the myriad ways of rebooting various flavors of Unixoid systems. Try kill -9 %1' to kill a background job and miss the % when you're logged in as the wrong user sometime. :) The question was why I didn't use -r. Usually, I tried, got the expected syntax error, cursed, and used the SysV flavor and gotten the order wrong. An error that I've never actually made while within 75 feet of the console :) pgp0.pgp Description: PGP signature
Re: [Full-Disclosure] SSH Exploit Request
How would updating ssh bring down a production system? http://www.gilliss.com/cgi-bin/presentation?title=Building+a+Backdoor+Binary; name=Backdoortotal=49rank=1 When I was writing this, I found *lots* of instances where the coding (mine, unfortunately) left the daemon(s) lying around doing gawd knows what on the system (and you hung your session besides). Console was the only reason that I got the code working so that I could do the presentation (not that I'd ever trojan an sshd on a system, for educational purposes only, ...) G On or about 2003.11.14 21:10:04 +, [EMAIL PROTECTED] ([EMAIL PROTECTED]) said: Well, *that* particular one is unlikely. But I've seen it happen. You install a borked build of ssh (shared lib dependencies are FUN), restart it, your session goes bye-bye, and you can't get back in to fix the runaway sshd that's chewing all the resources The more generic point is that in larger shops, you usually need to get *everything* planned and OK'ed in advance, including backout plans. And even then things go wrong. I'm sure I'm not the only sysadmin who's SSH'ed in to an ill box, decided a reboot was needed, and typed 'shutdown -i6 -g0 -y' (runlevel 6 to reboot, zero seconds grace, and don't prompt me), and instead realized 7 seconds later that what the other end *received* was '-i0 -g6 -y' (poweroff with 6 seconds warning), and made a bad situation worse. What *I*'d like to know is how the transposition gremlins know that it's 2AM on a major holiday, or a snowstorm, or other reason that the NOC is running lights-out and nobody's there to push the button to power it back on.. -- Gregory A. Gilliss, CISSP E-mail: [EMAIL PROTECTED] Computer Security WWW: http://www.gilliss.com/greg/ PGP Key fingerprint 2F 0B 70 AE 5F 8E 71 7A 2D 86 52 BA B7 83 D9 B4 14 0E 8C A3 ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
At 10:13 PM 11/14/2003 -0600, Paul Schmehl wrote: Nope. But I sure do in a lot of other unixes. Wasn't thinking of Solaris at the time. Sorry. 'shutdown -g -i[n] -y' is the System V command 'shutdown now' is BSD. IIRC, SunOS used the BSD version, but starting with SunOS 5.5 they switched to System V shutdown. m5x ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: We need to test it before we are permitted to upgrade. Please help. Help yourself and redesign your patch management. Yeah. Everyone can do that, smartass. No, he's right. The OP's environment apparently requires that there be testing before they're allowed to upgrade. That's *broken*. Plain and simple. Testing can reveal the presence of flaws, but not their absence - Dijkstra. How many people have trouble getting *known* *good* exploits to run in their environment? Now think hard here - if the exploit *works*, then yes, you have a problem. But if it doesn't work, *it doesn't prove the problem is actually fixed*. So you end up in a situation where you have *known* vulnerable boxes, and a fix to install, and the fix isn't being installed because you're busy trying to verify if the patch actually works, or if you simply have a defective exploit that would have worked if you had used gcc 2.96 instead of gcc 3.3 (a *known* issue for a lot of exploits), or if you had too many environment variables and something moved around in memory, or So let's see.. We have a fix from the vendor/maintainer that is claimed to fix the problem. The canned exploit doesn't work. Now, it's POSSIBLE that your exploit is b0rked, the fix didn't work, and if you changed something the exploit would work. Now how much effort are you going to put in to that testing (assuming that you're qualified to do it), while you have vulnerable machines in production? *That* is why the OP's patching scheme is broken. pgp0.pgp Description: PGP signature
RE: [Full-Disclosure] SSH Exploit Request
I am failing to see the logic in some of these issues here... A service is flawed in one way or another, patch it! If the vendor says the service is broke in some way, believe them, get off your lazy ass and get patching. If you are the admin, do your job and quit whining! Since that argument throws about the sniveling of, We can't afford the downtime of a server reboot, then think of it this way, with services such as SSH, a restart of the SSH Service does NOT shut down the whole server or kill active connections, instead it's a 2 second lapse where the server will refuse the connection, in which super important person Z will just have to rety to connect. If that is not good enough for you, then think of it another way, while you sit there thinking about if it is reasonable to take the 5 minutes out of your day to compile updated packages and install them as needed, some skript kiddie is going through your server looking for more toys to play with on your network. If the reluctance in patching is due to upsetting someone whom can't afford the downtime, think about your job security after your network is breached and you did not take the initative to repair a critical flaw anyway. I am quite bothered out the ass by well paid admins that are too damn lazy to spend the few minutes it takes to repair a flawed service. Either start doing your job, or get the hell out of the way for those of us that want to do the job required properly! RKD -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 11:08 AM To: Jeremiah Cornelius Cc: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] SSH Exploit Request On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: We need to test it before we are permitted to upgrade. Please help. Help yourself and redesign your patch management. Yeah. Everyone can do that, smartass. No, he's right. The OP's environment apparently requires that there be testing before they're allowed to upgrade. That's *broken*. Plain and simple. Testing can reveal the presence of flaws, but not their absence - Dijkstra. How many people have trouble getting *known* *good* exploits to run in their environment? Now think hard here - if the exploit *works*, then yes, you have a problem. But if it doesn't work, *it doesn't prove the problem is actually fixed*. So you end up in a situation where you have *known* vulnerable boxes, and a fix to install, and the fix isn't being installed because you're busy trying to verify if the patch actually works, or if you simply have a defective exploit that would have worked if you had used gcc 2.96 instead of gcc 3.3 (a *known* issue for a lot of exploits), or if you had too many environment variables and something moved around in memory, or So let's see.. We have a fix from the vendor/maintainer that is claimed to fix the problem. The canned exploit doesn't work. Now, it's POSSIBLE that your exploit is b0rked, the fix didn't work, and if you changed something the exploit would work. Now how much effort are you going to put in to that testing (assuming that you're qualified to do it), while you have vulnerable machines in production? *That* is why the OP's patching scheme is broken. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu November 13 2003 08:07, [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: We need to test it before we are permitted to upgrade. Please help. Help yourself and redesign your patch management. Yeah. Everyone can do that, smartass. No, he's right. The OP's environment apparently requires that there be testing before they're allowed to upgrade. That's *broken*. Plain and simple. But... He may work for an organization that a) makes him responsible for function, and isolated from policy influence (possibly broken). b) in which his manager is politically isolated (broken). c) is subject to a DITSCAP-style regime of testing and documentation processes - - not broken! In any case - it is unhelpful an peevishly arrogant to spit out change your process. O.K. That may be happening over time. What can I do /now/? Not pointing out the obvious - gobbles exploit code - leads to this kind of meta-thread, which has been the cause of so much grievance to some. A simple reply about the exploit and currency would have been entirely on topic for the list! -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/s8eCJi2cv3XsiSARArHKAKDq2u91UdBYxMz9RUMkNycgnnS5zgCeM8ks 9j8V9ZJoeQpC3wVFG9Sj+ak= =TGLt -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Robert Davies wrote: I am failing to see the logic in some of these issues here... A service is flawed in one way or another, patch it! If the vendor says the service is broke in some way, believe them, get off your lazy ass and get patching. If you are the admin, do your job and quit whining! Carefully read the subtext in his note. He would like an exploit if possible (or at least that's his claim) so that he can prove to someone else that yes, it DOES need to be patched, right now. I.e. he's got a boss with pointy hair that isn't cooperating. You don't have to believe his story. Having dealt with many bosses (my own, or someone else's) exactly like that, I'm willing to entertain his story. Calling the admin who wants to apply the patch, but isn't allowed to without jumping through hoops, lazy or stupid doesn't help anyone. BB ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
This is not a flame!! I'm just wondering if announcing to a list full of people both good, and bad who are able to exploit an old bug that I have an un-patched system is good security practice? I got rooted after simply replying to an ass-hole asking if any one thought they where being spied on by the US Gov off the list it was an old MDK8.1 box I was trying to keep around just a minuet or two longer and didn't have time to patch properly. (My Bad) My 2 cents Adam On Thursday 13 November 2003 01:03 pm, Jeremiah Cornelius wrote: On Thu November 13 2003 08:07, [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2003 02:18:57 PST, Jeremiah Cornelius said: We need to test it before we are permitted to upgrade. Please help. Help yourself and redesign your patch management. Yeah. Everyone can do that, smartass. No, he's right. The OP's environment apparently requires that there be testing before they're allowed to upgrade. That's *broken*. Plain and simple. But... He may work for an organization that a) makes him responsible for function, and isolated from policy influence (possibly broken). b) in which his manager is politically isolated (broken). c) is subject to a DITSCAP-style regime of testing and documentation processes - not broken! In any case - it is unhelpful an peevishly arrogant to spit out change your process. O.K. That may be happening over time. What can I do /now/? Not pointing out the obvious - gobbles exploit code - leads to this kind of meta-thread, which has been the cause of so much grievance to some. A simple reply about the exploit and currency would have been entirely on topic for the list! ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html -- -BEGIN PGP PUBLIC KEY BLOCK- Version: OpenKeyServer v1.2 Comment: Extracted from belgium.keyserver.net mQGiBDvODnIRBAD6ex+LS95ar546tDkRgaAv9T9RMle24L9xAmwkychQ6yL8LdNP kSZc6ErAUlMR1ygEGYAppWyBWrA6GFFijbfvX9pH7r2r5JdDv4X30ZlUAmbdeJub GfvGk63/JpEheLictj6A7xPb2+9mIpJ1g/AP5Eyxa+1V7pOqZzaFST2otwCg/8ql aJrMR6GQ+iDhwdo8wvI/D/sD/2rJkqAKr1Y6PoL70y0qqv/KbAxvViAl/HNfYk1g gL1YyqF1xNO5AgxzMS/KGHdYw+rWlbfjRuCJO813OT1/yefZbahModayyinlh8IN x9U8rs0sIOmpWMaMT3WvC75lcndV9Tfs/r8/SpYuU0wH2Xym5vJG1TLWRegdy3E6 PYpCA/9NT/1zbQS8haRkFUCZt6c7D0PRw4gT2bKhC7563x2xcRGPWKBXz0X1s6bb D5g9uitibnFo0F/MGK/v1NU5Z7vCgEXJsv+B5VRsnPloT1WEoYZ/IYUb0NlUszKf cI7rvaBjZ00SqivtDECefpNAjSfl5EJ+0ZCZgo2xjCfiQ0T1a7QmQWRhbSBQLiBI dW50IDxhZGFtQGh1bnRyZWNydWl0aW5nLmNvbT6ISQQQEQIACQUCPJeCgQIZAQAK CRDfxArjO/C7CAmjAJ4q9EpvuNpvi5BlBR7MfOfTo8VRaACg5Rka3nw40myMDBZZ QYUxQ36CVGu5Ag0EO84OchAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg 2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvO meFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YA WCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtV jLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIH/RAtkqoEqDD7 n1ykPPGNtSJ1sNZG6ENonnNGEOMXyb5X3oINxMNTO4UZtuYNkfRMwCvNb+on4Swa 7L+GVwuzJgH87QbFk1htxxzj7FS+4aXHf24QQSLSzGbYEZqFxyg6gXB34q9yGFNa ELMO6LyiL2sFykXw0P9+VNCOEqgMJQ+wTLttkFclSf8ycm7PYqsHAtgKk3fEUdoJ ILkrxe5+G+2hHv8ACav8nBcKnt/V9CK69TTWbfsNlRQRP5SggiPUsmraQHDvak51 QOqsupOXOeE7GBGUUYBgOkq/6hbRF4BHHugngoeZgfCcWtELvL/suQY+LZshIxZo BhxYvDx9XxC5Ag0EPJbF0BAIAPZCV7cIfwgXcqK61qlC8wXo+VMROU+28W65Szgg 2gGnVqMU6Y9AVfPQB8bLQ6mUrfdMZIZJ+AyDvWXpF9Sh01D49Vlf3HZSTz09jdvO meFXklnN/biudE/F/Ha8g8VHMGHOfMlm/xX5u/2RXscBqtNbno2gpXI61Brwv0YA WCvl9Ij9WE5J280gtJ3kkQc2azNsOA1FHQ98iLMcfFstjvbzySPAQ/ClWxiNjrtV jLhdONM0/XwXV0OjHRhs3jMhLLUq/zzhsSlAGBGNfISnCnLWhsQDGcgHKXrKlQzZ lp+r0ApQmwJG0wg9ZqRdQZ+cfL2JSyIZJrqrol7DVekyCzsAAgIH/0/nO38lPuZy pxRmBe7MBrrCLLuAhGNLq1oCTuA6JNCba7933x6vicdFrEJaIpDPWe7EVHyBJ+a6 ndLcOC8TLruuKXJY9R9oQEmKRSpjd2qDrOraglCvPeI3erQY99uxhNf/vMnBVVfF wf1JbOUEDc4oXyjXk57rHkKrWkveNpBYFwdnIbott9svjwn0EAHI8jxXErQjboKq 8gYQfUdldVndkYz7AQlzrAV0sJSZIjLtzvfX7j26OLBYC0t9P8yG4cKDCGOWAhqs 1lhiZ6bm6Yq9RGKc4Cfk57BwYtGVNE6qsFc8kK/rx0zW+sYvCfHUqoahsyTf4wHC oOHeBlITx4qITAQYEQIADAUCO84OcgUbDAAKCRDfxArjO/C7CMbEAKD6A0Sm p5OL5HxXOUkvSiGpSgRfMQCcDwaavQvsZcL4pO5xc90gm0ZdOUw= =jeF/ -END PGP PUBLIC KEY BLOCK- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] SSH Exploit Request
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Davies Sent: Thursday, November 13, 2003 11:09 AM To: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] SSH Exploit Request I am failing to see the logic in some of these issues here... A service is flawed in one way or another, patch it! If the vendor says the service is broke in some way, believe them, get off your lazy ass and get patching. If you are the admin, do your job and quit whining! Never heard the phrase, Never criticize a man until you've walked a mile in his shoes, Robert? Since that argument throws about the sniveling of, We can't afford the downtime of a server reboot, then think of it this way, with services such as SSH, a restart of the SSH Service does NOT shut down the whole server or kill active connections, instead it's a 2 second lapse where the server will refuse the connection, in which super important person Z will just have to rety to connect. In some people's worlds, they don't get to make those decisions. Yet you would toss them out in the street for incompetence because you are so much more competent? I am quite bothered out the ass by well paid admins that are too damn lazy to spend the few minutes it takes to repair a flawed service. Either start doing your job, or get the hell out of the way for those of us that want to do the job required properly! I'm equally bothered by people who think they have all the answers and anyone who doesn't think they way they do is incompetent. So, now we're both equally bothered, and yet we haven't accomplished a thing. Frustrating, isn't it, Robert? Maybe we should concentrate on our own problems and let other people solve theirs? Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Thu, 13 Nov 2003 12:08:41 EST, Robert Davies [EMAIL PROTECTED] said: I am quite bothered out the ass by well paid admins that are too damn lazy to spend the few minutes it takes to repair a flawed service. Either start doing your job, or get the hell out of the way for those of us that want to do the job required properly! Actually, the *original* problem was that the OP *wanted* to apply the patch to fix a flawed service, but was prevented from doing so by a flawed policy. Now tell me - would *you* install the patch anyhow, knowing that (possibly) doing so without all the change-control paperwork being done correctly would mean your ass would be canned and you'd be looking for another job? pgp0.pgp Description: PGP signature
RE: [Full-Disclosure] SSH Exploit Request
-Original Message- **snip** Actually, the *original* problem was that the OP *wanted* to apply the patch to fix a flawed service, but was prevented from doing so by a flawed policy. Now tell me - would *you* install the patch anyhow, knowing that (possibly) doing so without all the change-control paperwork being done correctly would mean your ass would be canned and you'd be looking for another job? That is dependant on the seriousness taken to network security. I for one feel that the less time a vulnerable service is open, the less time someone can move in and exploit it. I know, I may sound like a dick, but when it comes down to it, after testing the patch on a non-production machine and verification that the service is working properly, that is all the time needed to patch a flawed service. Maybe in large corporate environments, all the restrictions and flawed policies cause more problems then needed, but in that case, I really would not want to see them cry that they have been comprimised because they take their time with paperwork. I feel I would rather justify downing a service for one minute then having to explain why the system has to be taken offline for a few days while the drive is cloned and an attack is researched. I do apologize for assuming those that do not do the appropriate research and patching in a timely manner lazy, whereas its possibly the suits and policy writers that are definitely more to blame. IMO, I would do the patching as soon as I found the patched service suitable, and if I lost my job, at least I know that's one more machine that was secure under my control. I'd rather tell a prospective employer that I was canned for taking security precaustions then canned for having a critical machine comprimised. Once again, my apologies for getting all worked up over this, I just hate to see when suits slow down proper and prompt security precautions and then cry about being comprimised before they cut through the red tape. RKD ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
On Thu, 2003-11-13 at 13:19, [EMAIL PROTECTED] wrote: On Thu, 13 Nov 2003 12:08:41 EST, Robert Davies [EMAIL PROTECTED] said: I am quite bothered out the ass by well paid admins that are too damn lazy to spend the few minutes it takes to repair a flawed service. Either start doing your job, or get the hell out of the way for those of us that want to do the job required properly! Actually, the *original* problem was that the OP *wanted* to apply the patch to fix a flawed service, but was prevented from doing so by a flawed policy. Now tell me - would *you* install the patch anyhow, knowing that (possibly) doing so without all the change-control paperwork being done correctly would mean your ass would be canned and you'd be looking for another job? Change Control paperwork is the bane of security folks. I have most often been on the network/firewall side of things and had been expected to block access at the network level to make up for slow patching from the sysadmin side. I was at least lucky enough to have a management chain that understood the importance of security enough to verbally approve any reasonable requests from our team on short notice. There is definitely a need for change control and regression testing. Especially when microsoft servers are concerned. Who hasn't seen a site go down or a computer bluescreen or something equally fatal to the system after a microsoft patch was applied? They obviously can't be bothered to test their software, so its up to users concerned with uptime to test it themselves before applying patches to production servers. But it really does take both sides to keep systems safe. Not everything can be filtered at the network level, and threats are not exclusively from the internet. Unhappy employees or otherwise compromised machines can further exploit the internal network. -- Scott Taylor - [EMAIL PROTECTED] BOFH Excuse #209: Only people with names beginning with 'A' are getting mail this week (a la Microsoft) ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] SSH Exploit Request
Carefully read the subtext in his note. He would like an exploit if possible (or at least that's his claim) so that he can prove to someone else that yes, it DOES need to be patched, right now. I.e. he's got a boss with pointy hair that isn't cooperating. You don't have to believe his story. Having dealt with many bosses (my own, or someone else's) exactly like that, I'm willing to entertain his story. Calling the admin who wants to apply the patch, but isn't allowed to without jumping through hoops, lazy or stupid doesn't help anyone. Uhm, if his boss is that way to an admin that's asked to secure a box/set of computers I personally wouldn't work there. There is too much on my head then. Your boss should respect what you say and what you know and allow you to do your job instead of wanting to do it himself. Anyhow, I personally don't want a DCOM For nix... Since I know of a LOT of boxes that haven't been patched yet. There is really no need for a 'box and shipped' version of the vuln. There is a whitepaper out... Go read it and figure it out yourself. Moo~ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Robert Davies wrote: A service is flawed in one way or another, patch it! If the vendor says the service is broke in some way, believe them, get off your lazy ass and get patching. If you are the admin, do your job and quit whining! The OpenSSH maintainers lured Debian into distributing a vulnerable OpenSSH version by issuing a security advisory (the version distributed by Debian at that time was not vulnerable). I'm sorry, things aren't always as easy as you assume. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] SSH Exploit Request
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Davies Sent: Thursday, November 13, 2003 2:46 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: [Full-Disclosure] SSH Exploit Request I do apologize for assuming those that do not do the appropriate research and patching in a timely manner lazy, whereas its possibly the suits and policy writers that are definitely more to blame. IMO, I would do the patching as soon as I found the patched service suitable, and if I lost my job, at least I know that's one more machine that was secure under my control. I'd rather tell a prospective employer that I was canned for taking security precaustions then canned for having a critical machine comprimised. Your heart's in the right place, Robert, but you would have been canned for insubordination, *not* for taking security precautions, and any interviewer worth his salt would understand that as soon as you explained why you were fired. Once again, my apologies for getting all worked up over this, I just hate to see when suits slow down proper and prompt security precautions and then cry about being comprimised before they cut through the red tape. They don't cry about it. They fire the very security people that were screaming at them for not patching in a timely manner, blaming them for not protecting the organization. And once in a great and wonderful while, they say, You were right. How long did you say it would take to implement that solution? Such is life in never-never land. If you *really* want to make a difference in security, you stay where you are, work within the rules and fight like a banshee for what you know is right. Then, when they finally get it, you're a hero, because you've been saying I told you so for a very long time. Nothing worth having ever comes easy, and seldom is anything easy to get worth having. Paul Schmehl ([EMAIL PROTECTED]) Adjunct Information Security Officer The University of Texas at Dallas AVIEN Founding Member http://www.utdallas.edu/~pauls/ ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Jeremiah Cornelius wrote: The last exploit for a critical vulnerability in OpenSSH is from 2001. You might be helpful - in some /small/ way: Google for gobbles and ssh Bingo! This vulnerability is not critical; it only affected a fraction of all deployed SSH systems. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Robert, I do apologize for assuming those that do not do the appropriate research and patching in a timely manner lazy, whereas its possibly the suits and policy writers that are definitely more to blame. IMO, I would do the patching as soon as I found the patched service suitable, and if I lost my job, at least I know that's one more machine that was secure under my control. This illustrates the conflict of being a systems and security professional and being an employed systems/security administrator/engineer/whatever. Your instinct to do what you know is in the best interests of protecting the resources (systems, applications, data) under your control is natural and certainly a necessary and admirable quality, however there is one critical overriding detail: You do not own the system. They do. Unless you define policy, own the systems, pay the bills or whatever gives you the real authority, the best you can do is to work to make sure that they are able to make the best, most informed decisions possible based on your expert advice. This includes details of systems security and threats, as well as policy and process. Try to improve the system from within - use the change control process, document issues, make sure you address your audiences in terms appropriate to them (which does not mean to dumb down, but to accurately convey information which they can understand well enough to make decisions based in it). In the end, if you cannot accept the decisions made by them after you have made a genuine effort to address what you consider to be the serious issues affecting your duties and responsibilities, then you have the authority to find a better job. Either way, the reward in the end is when you get regularly asked, What do you suggest?. I'd rather tell a prospective employer that I was canned for taking security precaustions then canned for having a critical machine comprimised. Presuming s/then/than/, the potential employer will be happier to hear that on more than one occasion you advised your management of the threat, provided solutions, worked with management to fix them problem then resigned after the systems were compromised because you felt your professional expertise was not being valued or used. -Andrew- -- ___ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | | They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety - Benjamin Franklin, 1759 | ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] SSH Exploit Request
Thus spake Florian Weimer ([EMAIL PROTECTED]) [13/11/03 18:33]: The last exploit for a critical vulnerability in OpenSSH is from 2001. You might be helpful - in some /small/ way: Google for gobbles and ssh Bingo! This vulnerability is not critical; it only affected a fraction of all deployed SSH systems. Yes, but if the vulnerability affects the original posters systems, then he has what he needs. It doesn't matter that his systems are a part of this fraction, it matters that they are vulnerable. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
