Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: Bug in scp v3.0.1
From: "Jonathan A. Zdziarski" <jonathan () cafejesus com>
Date: Wed, 31 Oct 2001 16:40:37 -0500

Looking at a truss, if a program was calling usleep (or some other method of
delay) you would see something like this:

nanosleep(0xbfbffb8c,0x0)                        = 0 (0x0)

However doing a truss on scp2, I see this repeatedly:

gettimeofday(0xbfbffa04,0x0)                     = 0 (0x0)
gettimeofday(0xbfbffa04,0x0)                     = 0 (0x0)
select(0x6,0xbfbffaa4,0xbfbffa24,0x0,0xbfbff9f4) = 1 (0x1)
write(4,0x82666f7,244282)                        ERR#35 'Resource
temporarily unavailable'
gettimeofday(0xbfbffa04,0x0)                     = 0 (0x0)
gettimeofday(0xbfbffa04,0x0)                     = 0 (0x0)
select(0x6,0xbfbffaa4,0xbfbffa24,0x0,0xbfbff9f4) = 1 (0x1)
write(4,0x82666f7,244282)                        ERR#35 'Resource
temporarily unavailable'
gettimeofday(0xbfbffa04,0x0)                     = 0 (0x0)
gettimeofday(0xbfbffa04,0x0)                     = 0 (0x0)
select(0x6,0xbfbffaa4,0xbfbffa24,0x0,0xbfbff9f4) = 1 (0x1)
write(4,0x82666f7,244282)                        ERR#35 'Resource
temporarily unav^C

It looks like select is telling scp that there is at least one file
descriptor in the set it specified (i haven't looked at the source yet so I
don't know if that's the bug), however as you can see the write() command is
failing and is going through this cycle repeatedly without any delay.  The
two time calls in between each call can't help either.

What I can tell from a truss output is it appears that it's trying
repeatedly to write and looping without waiting.  I'll be looking at the
source soon.


-----Original Message-----
From: Nate Eldredge [mailto:neldredge () hmc edu]
Sent: Wednesday, October 31, 2001 4:31 PM
To: Jonathan A. Zdziarski
Cc: bugtraq () securityfocus com
Subject: Re: Bug in scp v3.0.1


Jonathan A. Zdziarski writes:
I was scp'ing a 2MB file to my home computer over a DSL line and just
happened to run top at the same time.  I immediately noticed this line:

13864 root       1  30    0 2884K 1744K run     0:38 42.00% sshd2

It appears that scp'ing a file over a slow connection causes the process
to
suck up a huge number of resources.  There's most likely no usleep()
somewhere it's needed.  A couple scp's over slow connections could
severely
degrade the boxes performance.

I've noticed this but always assumed it was just that encryption is a
cpu-intensive operation, and that was how much CPU it took to encrypt
the data at the rate it was being sent.  Are you sure it's using more
than it really needs?

Unless sshd was written by a completely insane person, it will encrypt
what data it has, then sleep in `read' or `select' waiting for more.
In this case it will use as much cpu as it takes to keep up with the
data.  This seems perfectly reasonable to me.  Encryption is a
cpu-intensive operation, and you have to pay the cycles somehow; might
as well take them when you need them.

`usleep' wouldn't be the fix, either; that would just slow down the
copying.

I'm not sure how this is a security issue, anyway; if someone can scp
files, then they can log in via ssh.  So they could just run several
dozen processes doing `for(;;);'.  That will likely degrade
performance a lot more.

This test was performed on a Solaris 8_x86 machine.

How fast a machine?  38 seconds of cpu to encrypt 2 megs of data does
seem a bit high for modern machines.  But on an older machine, I'd
believe it.

--

Nate Eldredge
neldredge () hmc edu




  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault