| |||||||||||
The OpenSSH vulnerability and the disclosure processThe OpenSSH vulnerability and the disclosure processPosted Jul 4, 2002 2:57 UTC (Thu) by jasone (subscriber, #2423)Parent article: The OpenSSH vulnerability and the disclosure process Perhaps the OpenSSH developers had good intentions when they decided how to divulge the security problems with their software, but in practice there were serious problems with their approach. Forcing users to update to the most recent release is unreasonable. Anyone with a basic understanding of software engineering knows that as changes are made to software, corresponding bugs are introduced (statistically speaking). Perhaps there are many important fixes in the newest release, but there are also feature additions, which surely means new bugs. For me personally, the OpenSSH team's disclosure strategy was equivalent to a denial of service attack, since I felt the only reasonable option was to disable ssh completely until I could assess the vulnerability of my systems.
(Log in to post comments)
The OpenSSH vulnerability and the disclosure process Posted Jul 4, 2002 8:00 UTC (Thu) by beejaybee (guest, #1581) [Link] > Perhaps the OpenSSH developers had good intentions when they decided how to divulge the security problems with their software, but in practice therewere serious problems with their approach. Same applies to ISS... In principle I want to know that I can _expect_ an attack. Vigilance is perhaps the most important part of system security, though it is certainly expensive in human resources; directed vigilance at specified highlighted weaknesses therefore helps (though is, of course, not adequate in itself). > Forcing users to update to the most recent release is unreasonable. Agreed. Though in this case the changes from (say) v3.1 to v3.4 are not hard to assimilate in a working environment. Ideally I'd like to have seen "official" backported patches for the 3.x series as well as the release of v3.4. That would have given us a choice between jumping to v3.4, waiting for an official release (in some cases of an unofficial backport) from our favoured supplier, or accepting reduced functionality. However the OpenSSH team certainly deserve credit for the speed with which they acted, and the way in which their action uncovered other vulnerabilities. > I felt the only reasonable option was to disable ssh completely until I could assess the vulnerability of my systems. Your choice. My personal view is that a service must be maintained, and that withdrawing SSH would only encourage the deployment of other protocols (telnet, ftp, rcp, rlogin etc) which by their very nature are more risky than SSH. If you're really paranoid, disconnect your system from the Net - that's the only way to be absolutely sure you won't suffer remote compromise!
The OpenSSH vulnerability and the disclosure process Posted Jul 4, 2002 8:24 UTC (Thu) by edmundo (guest, #616) [Link] "withdrawing SSH would only encourage the deployment of otherprotocols (telnet, ftp, rcp, rlogin etc) which by their very nature are more risky than SSH" I'm not sure about that: telnet is vulnerable to packet sniffing, but By the way, there is at least one alternative implementation of sshd:
The OpenSSH vulnerability and the disclosure process Posted Jul 4, 2002 10:08 UTC (Thu) by beejaybee (guest, #1581) [Link] > I'm not sure about that: telnet is vulnerable to packet sniffing, butat least a bug-free telnetd is safe against worms and script kiddies. Umm. Telnet access to your host is vulnerable to keystroke trapping on any system used to access your host, as well as packet sniffing. Even if you only give away an unpriveleged username/password combo, ways may exist to exploit this directly or through privelege escalation due to bugs in unrelated programs. System compromise is a problem relevant to ssh/telnet/ftp style access; but worms aren't, since there is no direct way for them to propogate, unless the system has already been compromised. There seem to be a lot of systems around running versions of telnetd which are undoubtedly not bug-free; even those versions of telnetd which have no _known_ vulnerabilities are in any case probably just as insecure as ssh. I stand by my previous comment.
|
|||||||||||