Slashdot Mirror

...they're hardly being original!

except I WANT color highlighting to be printable! why is it that no programmer's editor cannot print the highlighting in color?

Could that be because most programmers don't really do that much printing of code? I haven't printed out any source since my form-feed dot matrix printer died years and years ago.

That said, pipe your code through GNU enscript to print it, and it should generate some decent syntax hilights. Also, if you're interested in publishing code with hilighting to a web page, Vim can output to html using the currently selected hilight mode.

With the monthly (if not more often) security problems with that package its the reason why I stick with this instead.

I just don't have the time to constantly update my home systems like this.

Each time I see a vulnerability report about OpenSSH, I wonder whether the vulnerability is also present in plain SSH. Finland's site doesn't seem to have any information on security advisories, at least not in any obvious place.

Each time I see a vulnerability report about OpenSSH, I wonder whether the vulnerability is also present in plain SSH. Finland's site doesn't seem to have any information on security advisories, at least not in any obvious place.

Should the US prohibit the export of high-encryption software?

Sure, why not? It isn't as if there are any cryptographers in any other countries in the world, is it?

Legislation is pointless, and even damaging in this case. The cryptography playing field is fairly level. That's not inherently a good or a bad thing; just as al-Queda can encrypt their files, they are equally prevented from intercepting sensitive information by the same technology. If legislation restricts crypto, we will find ourselves in a situation in which the FBI can't crack terrorist comms, yet terrorists can intercept commercial data. Airline security information, oilrig blueprints, whatever.

IDEA-encryption is actually already implemented on many clients: irssi, irchat and ircii too (can't find a link though). This is technically far more better than SSL-encryption to the server since it encrypts end-point to end-point.

Well, the other argument, besides the time delay, is that the trademark became diluted even before OpenSSH existed. SSH isn't just the name of a product, it's also the name of a protocol that many programs use. So a lot of the time when people talk about "ssh", they are not referring specifically to the product sold by SSH Communications Security Corporation. For example, if you sold me a shell account on your box, I would ask you, "Do you support SSH logins?" But I wouldn't actually be asking whether you run SSHCS's product or not.

Thus, due to his decision to name the protocol and the product the same thing (and encouraging others developers to also use the protocol), he caused "SSH" to not be

a device (as a word) pointing distinctly to the origin or ownership of merchandise to which it is applied and legally reserved to the exclusive use of the owner as maker or seller

Both born here.

SSH Tatu Ylönen
F-Secure Half of my friends work there (suckah's ;)

It's not the end of the list but those are some cool things born here. As for cool geek stuff from Finland, you might want to check out Oulu as well - would 'IRC' ring a bell?

Anyway, rootshell.com may have been hacked because of an SSH overflow. They've never stated it publicly (don't they believe in full disclosure?), but they clearly implied it and ranted about how SSH Communications lied about this attack.

-----------------------
[10/28/98 8:44AM PDT -- Rootshell Defaced]
On Wed Oct 28th at 5:12AM PST the main Rootshell page was defaced by a group of crackers. Rootshell was first informed of this incident at 6:00 AM PST and the site was immediately brought offline. The site was back up and operational by 8:00AM PST.

We are still in the process of investigating the exact methods that were used. The paranoid MAY want to disable ssh 1.2.26. Rootshell runs Linux 2.0.35, ssh 1.2.26, qmail 1.03, Apache 1.3.3 and nothing else. The attackers used further filesystem corruption to make it harder to remove the damaged HTML files.

More information about SSH may be found at http://www.ssh.fi/sshprotocols2/index.ht ml

rootshell.com - Archive of defaced site.

rootshell.com - Security bulletin #25

----------------------
[11/2/98 8:07AM PST -- IBM ERS responds to Rootshell Security Bulletin #25]
The following was received this morning by Rootshell. IBM maintains that distributing their advisory was irresponsible as no proof of an actual exploit has been found. We maintain that information of a POSSIBLE exploit is still doing a service to our readers and will continue to make information such as this available. This is one of the differences between a service like ERS and Rootshell. Rootshell comments are enclosed in []'s. Since you irresponsibly distributed a draft of our advisory to further your own agenda, perhaps you will now responsibly distribute the following.

A simple telephone call from you before you issued this could have saved us all a lot of hassle.

[ Apparently you do not believe in full disclosure then. ]

--Dave

On Friday, Oct. 30th, IBM-ERS sent out a draft advisory to be released on Monday, Nov. 2nd that described a buffer overflow condition in Version 1.2.x "sshd." This draft was sent to the Forum of Incident Response and Security Teams, and also to the "ssh-bugs" list for their comment/review. The draft was identified as ERS-SVA-E01-1998:005.1.

Rootshell has unfortunately chosen to include a copy of this draft advisory in their recent newsletter, apparently for the purposes of defending itself against charges that it was unfairly disparaging "sshd." Use of IBM-ERS's draft advisory in this manner was not approved or authorized by IBM-ERS, and does a disservice to all.

[ Making the facts known to the public is hardly a disservice. To quote your own advisory. "The material in this security alert may be reproduced and distributed, without permission, in whole or in part, by other security incident response teams (both commercial and non-commercial), provided the above copyright is kept intact and due credit is given to IBM-ERS." ]

Here are the facts about this advisory:

1. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was never issued publicly by IBM.

[ Neither was the Rootshell advisory by your standards. The Rootshell advisory was sent to a private collection of 26,000+ members of the security profession. ]

2. In response to a telephone query from Kit Knox of Rootshell, IBM-ERS attempted to contact Kit on Friday evening, and was unable to reach him. Specific contact information for IBM-ERS, as well as a brief status update, were left on Mr. Knox's voice mail. Mr. Knox never contacted IBM-ERS after that time.

[ Note: Not a single e-mail was received. We live in the digital age folks. My PGP key is also in the key servers if security was a concern. Or don't you trust PGP? ]

3. IBM has been working closely with Tatu Ylonen, author of "ssh," to make sure that the potential vulnerability described in the advisory is not exploitable. Upon further investigation, the problem originally described appears to have been influenced by outside factors and does not appear to be an exploitable problem in "sshd."

[ Rootshell NEVER has made any claims of an actual exploit. ]

4. IBM-ERS advisory ERS-SVA-E01-1998:005.1 was CANCELLED on the morning of Sunday, Nov. 1st, *before* Mr. Knox issued his newsletter.

[ Cancelled to your PRIVATE ~61 member list at FIRST. ]

5. At this time, IBM-ERS has NO KNOWLEDGE of any security vulnerabilities, exploitable or otherwise, in the "sshd" program.

[ We have never said otherwise. ]

We hope that this clarifies IBM's involvement in this situation.

The information in this document is provided as a service to customers of the IBM Emergency Response Service. Neither International Business Machines Corporation, nor any of its employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, complete- ness, or usefulness of any information, apparatus, product, or process contained herein, or represents that its use would not infringe any privately owned rights. Reference herein to any specific commercial products, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation or favoring by IBM or its subsidiaries. The views and opinions of authors expressed herein do not necessarily state or reflect those of IBM or its subsidiaries, and may not be used for advertising or product endorsement purposes.

rootshell.com - Security bulletin #25

------------------
[11/5/98 8:44AM -- SSH Admits Buffer Overflow in 1.2.26 client]
This morning SSH Communications Security LTD. released information about a buffer overflow in its ssh 1.2.26 client kerberos code. This came as quite a surprise after SSH was very bullish about there being no buffer overflows in their code. While it is VERY hard to exploit and only works under certain conditions, it is still a valid security hole. PLEASE REMEMBER, ROOTSHELL HAS NEVER STATED THAT THE BREAK-IN WE HAD WAS FROM A SECURITY HOLE IN SSH. Anyone who believes otherwise has read too far into what we have said.

rootshell.com - Official statement from SSH

It would be nice if some of the real security people out there would work toward a standard of intersystem daemon security. An SSH (SECIP) style public-key with trust (signed keys -- like PGP/GPG) system (in a library) that could be linked against by all those making daemons. BIND could link against it to authenticate messages it sends and receives, so could PING (for those of us who don't like pingfloods) and X.

Each daemon is starting to add its own security (Cyrus IMAP has several options) and they aren't inter-compatible. If there were a common library they were based on, it could be improved upon by all parties involved.

Hate to point out one of the greatest benefits of open source -- shared library code that you can modify -- and also one we are bad at actually doing.

- Michael T. Babcock <homepage>

1. Well.. you don't really have a choice. You have to get your DHCP from USWest, no two ways about it. As far as security, the only thing anyone could gain by messing with DHCP transmissions to and from your computer is a useless denial-of-service attack. Nothing to worry about there. DSL in general is as secure as any other internet connection - it's less secure than a dialup line just because you're not connected all the time, but it's not much different than T1 or any other full-time connections in that regard.
   
2. A firewall inspects every packet that it is instructed to and does any one of a number of things to it - drop the packet, permit it, etc. From this basic functionality you can set up security on your box such that certain ports / IPs are allowed to talk to it and others aren't. That's a gross oversimplification. You should check the Firewall-HOWTO that's available all over.
   
   A proxy server simply listens for requests from services (usually web) and goes out and does all the work. For example, Squid, a web proxy server, listens for web requests and then accesses the pages and sends them back to the computer that asked for them. The benefits of this are speed - Squid will remember what pages it's asked to retrieve most frequently, and save local copies of those so it can send them right off the hard drive instead of downloading them when it's asked.
   
   You should note that firewalls and proxies aren't mutually exclusive. Lots of people, myself included, run a firewall to keep the baddies out, and a proxy server to speed things up a bit.
   
3. Lots of people here will say yes. Just think of it this way: it's a bad idea to run any service that you don't need. Redhat 5.2, for example, ships with the mail, web, ftp, samba, nfs, rpc, finger, telnet, etc. servers all enabled. This is pointless; you probably don't need every single one of them (although some people do). Aside from taking up memory and CPU time, all these things you now have running have possible security holes in them. It's nt a linear scale, but disabling half your services would probably cut your chance of being hacked in half, so to speak. One word of advice to you would be to use encrypted sessions for whatever services you do decide to use. Telnet, for example, is just a glorified TCP/IP session, and is plainly readable to anyone that has the means to. Thus, if you're telnetting to your house across the internet, anyone can read your name, password, address, phone number - whatever you're typing in. Definitely I would use SSH and also stunnel for IMAP/POP across the internet. Your box is as secure as you make it - spend a lot of time upgrading to squash bugs, disabling unneeded processes, and using common sense, and you'll make your foes' jobs a lot harder.
   
4. Firewalls are not incredibly hard. It took me about two days of playing with IPCHAINS (the firewall program) and reading the HOWTOS to become proficient. Squid (proxy server), on Redhat, works pretty much out of the box. Only three or four lines to the Squid configuration file to get it up and running. Remeber that you can run other service on your firewall/proxy - mail, news, whatever. I run tons on mine.
   
5. Well, I'm using your configuration. RH 5.2 (too lazy to upgrade, as well) masquerading/firewalling/proxying six Windows 98 boxes, an iMac, and a powerbook. It's worked like a charm for months. I've never, once, had Linux crash. I'm far more worried about my 6 year old hard drive giving out at the moment than I am about the server going down. Good luck!
   
   
   

Red Hat can't package ssh, because they ship worldwide and ssh is defined as "strong cryptography" -- it is illegal to export strong crypto from the U.S. (And similar laws in other countries.) There's nothing (apart from local laws!) to stop you obtaining ssh yourself, from its home site or elsewhere, and some people do package it for the various distributions. Debian get round the problem by not including the export-controlled stuff in the standard distribution and telling people to go visit ftp.non-us.debian.org (or whatever it is, I don't remember for sure). Perhaps RedHat could include a user-friendly installer for ssh which would visit somewhere like ftp.export.redhat.com, download a (signed by RedHat) RPM and install it? >But really, does a home user even need telnet? Not most home users... I do, though. (well, I use ssh internally out of paranoia...)

SSH (Secure Shell) is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over insecure channels. It is intended as a replacement for rlogin, rsh, rcp, and rdist.

Other good points about SSH: it's from Finland, and the source should compile on all of the systems you've mentioned. SSH is at ssh.fi. Or, you could skip their icky web site, and just search at Freshmeat.

Basically, there was never a verifiable problem with SSH 1.2.26 (the version available when this whole incident took place). The IBM team that suggested a possible exploit (the same warning Rootshell latched on to in attempts to explain their compromise) ended up retracting their claim. However, panic and some politics have made this whole issue unclear.

1.2.27 took care of a hard-to-duplicate issue involving Kerberos support. And, as of right now, I'm not aware of any exploits at all against 1.2.27 (current version in the SSH1 tree).

I'd be glad to hear of any new developments I've missed out on. :)

Wassenaar "harmonization" threatens to make this true, but currently Finland atleast has very liberal encryption laws and hence is the source of ssh and the host of many open source encryption servers.
--