(This Webpage Page in No Frames Mode)

Welcome to Lachlan Cranswick's Personal Homepage in Melbourne, Australia

Software, Computer Security, Intrusion Detections and Stuff - Links

Lachlan's Homepage is at http://lachlan.bluehaze.com.au
[ Back to Lachlan's Homepage]
[What's New on Lachlan's Page]
[Intro - CranClan] . . [Happening Things] . . [The Daresbury Laboratory Web Ring of Life] . . [NCS - Non-Competitive Scrabble] . . [Garden Gnomes of Daresbury Laboratory] . . [Nature and Local UK Things] . . [USA 2001 and LDEO Columbia University] . . [Historical Literature/Poetry] . . [Music] . . [Misc Things] . . [DL SRS Status] . . [Conference and Travel Things] . . [The Wonders of Team Building] . . [Other People's Homepages] . . [Crystallographic Internet Front] . . [While in Melbourne] . . [Semi Relevant Links]

Stuff

Books to try out as well

To: Exploit-Dev
 Subject: Re: ssh-1.2.27 remote buffer overflow - exploitable
 Date:  Mon Nov 08 1999 21:24:17
 Author: Daniel Jacobowitz
 Message-ID: [19991109112417.A30046@drow.res.cmu.edu]


On Tue, Nov 09, 1999 at 01:48:53AM -0000, Frank wrote:
> This is submitted to the Freebsd bug tracking system, although there
> are doubtless other vendors who leave this package, despite the
> existence of the ssh-2.X.  While Debian appears to be immune, I was
> able to crash my ssh daemon (much to my dismay), and there appears
> the potential to execute arbitrary code, as long as you encrypt it
> first...
>
> Here is the freebsd report.. it describes the method to crash a
> remote Ssh daemon (lets hope you ran sshd from your xinetd, etc).
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=14749
>

And here's a patch.  Not tested, as I don't use the rsaref glue on any
machine here.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/

--- rsaglue.c.orig      Tue Nov  9 11:12:32 1999
+++ rsaglue.c   Tue Nov  9 11:17:58 1999
@@ -139,6 +139,10 @@

   input_bits = mpz_sizeinbase(input, 2);
   input_len = (input_bits + 7) / 8;
+  if(input_bits > MAX_RSA_MODULUS_BITS)
+    fatal("Attempted to encrypt a block too large (%d bits, %d max) (malicious?).",
+       input_bits, MAX_RSA_MODULUS_BITS);
+
   gmp_to_rsaref(input_data, input_len, input);

   rsaref_public_key(&public_key, key);
@@ -172,6 +176,10 @@

   input_bits = mpz_sizeinbase(input, 2);
   input_len = (input_bits + 7) / 8;
+  if(input_bits > MAX_RSA_MODULUS_BITS)
+    fatal("Received session key too long (%d bits, %d max) (malicious?).",
+       input_bits, MAX_RSA_MODULUS_BITS);
+
   gmp_to_rsaref(input_data, input_len, input);

   rsaref_private_key(&private_key, key);

  • 5.6. Can I use ssh to protect services like FTP or POP?

    5.6. Can I use ssh to protect services like FTP or POP?

    If you want to avoid sending FTP passwords in cleartext over the net, you can use ssh to encrypt your command channel. This will still leave your data channel open to all attacks on TCP, and will not work through a firewall.

    You can either use ftpsshd by Per-Erik Martin at http://www.docs.uu.se/~pem/hacks/ for SSH1, or you can do this by hand.

    SSH1: Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do 

    myhost$ ssh -L 1234:ftphost.example.com:21 ssh-server
    This logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost.

    Note: You need to use -g if you're forwarding to localhost (SSH1 only).

    Then, in another window, you do 

    myhost$ ftp localhost 1234
220 ftphost FTP server (Foonix 08/15) ready.
Name: (myhost:yourname):
331 Password required for yourname
Password:
230 User yourname logged in.
    This works if the remote ftp daemon accepts PORT commands which specify a different host from the one the command channel appears to come from, and if the ftp client always uses PORT. This is true for vanilla UNIX ftp client and ftpd servers; it may not work for more advanced ftpds, such as wu-ftpd.

    For servers which do not accept this, you can see wether you ftp client supports passive mode, and wether the ftp server accepts PASV.

    Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping.

    SSH2: Just use sftp instead. :-)

    For POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) has written a script which protects the mail transfer and passwords ussing ssh. It requires no modification to existing POP servers or clients, and is available from ftp://ftp.internatif.org/pub/unix/gwpop/ .

    Or, you can use similar means for secure POP: 

    myhost$ ssh -L 1234:popserver.example.com:110 ssh-server

    Other services could be secured by similar means.

    5.7. Can I use ssh across a Socks firewall?

    Socks 4 and 5 support should work in 1.2.16 or later. Socks support in version 2.0.11 and later should work. 

    • Newsgroups: comp.security.unix
Subject: Re: secure pop from sniffing
From: [bglbv@my-deja.com]
X-Newsreader: Gnus v5.7/Emacs 20.6
Date: 06 Jun 2000 20:29:54 +0100


"Bernd Dürrer" [duerrer@ika.ruhr-uni-bochum.de] writes:

> "kukulkan" [isman@fsksm.utm.my] schrieb im Newsbeitrag
> news:393C65B2.5A676C14@fsksm.utm.my...
> > any software/methods to secure pop(esp. Eudora users) from being sniff?I
> > have ssh  here to protect remote login and file transfer, but still it
> > has no meaning If I cannot have the pop to be secure ..

> You want to use the port forwarding capabilities of SSH: Have a look at
> http://www.employees.org/~satch/ssh/faq/ssh-faq-5.html#ss5.6
> 
> If this doesn't help you, please post what SSH implementation on what OS
> your pop users are using.

I don't think Eudora supports the SSH protocol at all.
What it might support is:

(a) APOP (Authenticated POP), which involves transmitting a (non-replayable)
hash of the POP password and of a challenge sent by the POP server.
The POP password is distinct from the password used for interactive logins.

(b) POP over an SSL tunnel (to port 995 rather than 110).

If I remember correctly, Eudora can do (a) but not (b), while Netscape
Messenger can do (b) [but not (a)?]. It's probably wise to support both.
And to make the POP passwords different from the login passwords in
any case.

Also make sure your POP server has no known security holes. (Some
versions of Qpopper are to be avoided, for example.)
     

    From: eitz@weh.rwth-aachen.de (Holger Eitzenberger)
Newsgroups: comp.security.unix
Subject: Re: secure pop from sniffing
Date: 7 Jun 2000 09:22:00 GMT
Organization: RWTH Aachen
Lines: 16

On Tue, 06 Jun 2000 10:45:06 +0800, isman@fsksm.utm.my (kukulkan) wrote:

>any software/methods to secure pop(esp. Eudora users) from being sniff?I
>have ssh  here to protect remote login and file transfer, but still it
>has no meaning If I cannot have the pop to be secure ..

You may want to use APOP (authenticated POP3), which i use also.  Both
QPopper (on server side) and fetchmail (on client side) support it.
APOP uses an encrypted one-time key to get mail.

Holger


-- 
+ GnuPG Public Key -> finger eitz@jonathan.weh.rwth-aachen.de +

    Using APOP at NCSA - What is APOP?

    • "APOP is a challenge-response authentication scheme built on top of the standard POP protocol. It's designed in a way that protects your password from ever being sent across the network.

      To keep your password safe, the server actually stores your password in a file on local disk. Whenever your mail client connects to the APOP server a magic string is sent back. That string contains a unique identifier for this session based upon the process id (PID) and current time. Here's a sample string (the special part is enclosed within angle brackets):

      +OK QPOP (version 2.53) at mx1.ncsa.uiuc.edu starting. <14156.916910505@mx1.ncsa.uiuc.edu>

      Your email program uses the text within those angle brackets to perform a mathematical calculation upon your password. The server also performs the same calculation on the password that it has stored locally. When your email program is finished with its calculations it sends a 128-bit "fingerprint" to the APOP server, which then compares that value with the one that was calculated locally. If both fingerprints match, then it knows that the same password was used to perform the calculation in both places.

      Since the string that the server sends is based on the current time and PID it's impossible for anyone to reuse it; each connection to the server results in a new challenge/response and calculation. "

    • At http://www.ncsa.uiuc.edu/General/CC/email/apop.html#whatis