Re: Multi format string bugs in IPAD x.x ftp server
On Sat, 17 Feb 2001, diab wrote: There appears to be multiple format string bug's in IPAD x.x ftp server. Here are some examples with the 'site' command: are you sure it's not an expansion/problem on the client end? telnet to port 21, login and try it there. sorry i don't have an IPAD box to test it on (care to share one?) but try that out. it's been the real problem before. jose nazario [EMAIL PROTECTED] PGP: 89 B0 81 DA 5B FD 7E 00 99 C3 B2 CD 48 A0 07 80 PGP key ID 0xFD37F4E5 (pgp.mit.edu)
Re: Virus Unix.penguin
I got a ton of autoreplies from AV software on this. The message did not contain a virus, the signature is triggered by a line in the exploit that contains the Unix commands to cat the password file through a pipe to the mail program. Of course, I won't quote the actual line, because then this message will trigger the same problem, but interested users can view the original message at: http://www.securityfocus.com/archive/1/163938 Yes, going to that URL may cause your AV software to act up again. Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com My Antivirus detected the Virus "unix.penguin" from mail By kanedaaa Bohater, Subjet CGI - Mailnews cgi vulnerability dated 20/02/2001. From Virus Encyclopedia: Unix.Penguin is a simple shell script which emails the unix passwd file to someone. This may allow others to gain information about a system. Luca
Re: Multi format string bugs in IPAD x.x ftp server
If I'm reading this correct. This appears to be format string bugs in your FTP client. Not in the server (notice the seg fault took you too your prompt) - Original Message - From: "diab" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, February 17, 2001 7:03 AM Subject: Multi format string bugs in IPAD x.x ftp server Hi ppl, There appears to be multiple format string bug's in IPAD x.x ftp server. Here are some examples with the 'site' command: [diab@epuj diab]$ ftp xxx.xxx.xxx.xxx Connected to xxx.xxx.xxx.xxx. 220 xxx.xxx.xxx.xxx FTP server (IPAD 2.52) ready at Wed Feb 14 16:08:08 2001 Name (xxx.xxx.xxx.xxx:diab): anonymous 331 Anonymous logins ok. Please enter your e-mail address as password. Password: 230 User anonymous logged in. Remote system type is MSDOS. ftp site %s%s%s%s%s%s%s%s%s%s%s%s%s%s Segmentation fault [diab@epuj diab]$ or: ftp site %x%x%x%x%x%x%x%x%x%x%x 500 Unknown command 'site 8057478806014080635400bfffcc784554495325782520257825782578257825782578257825 78' or: ftp site %p%p 500 Unknown command '8067efc68184013dab8684013db98' or: ftp site %c%c%c%c 500 Unknown command '2570(nil)(nil)(nil)(nil)(nil)(nil)(nil)(nil)(nil)(nil)(nil)(nil)(nil)0x4 etc ftp quit 500 Unknown command 'site 0.000.0098099176241206326244409344.00' [diab@epuj diab]$ Anyway I thought I might bring this issue to some people's attention. bye, - diab
Re: HeliSec: StarOffice symlink exploit
On Sat, Feb 17, 2001 at 04:57:23PM +0100, JeT Li wrote: One way to fix the problem is to create a directory inside your home directory which is inaccessible to anyone but yourself (permissions 700), called tmp. Then insert an entry in your login start-up file to set the $TMP environment variable to $HOME/tmp, so it will direct StarOffice to use your temporary directory, rather than the system /tmp. Something like this (in bash): [wushu@JeT-Li]$ TMP=$HOME/tmp ; export TMP (not permanent) or modify the .bash_profile adding TMP=$HOME/tmp and including this variable in the export. BTW, I have some fairly sophisticated TMPDIR/TMP scripts in the CVS repository for Bastille (http://sourceforge.net/projects/bastille-linux) that folks might find useful. The scripts allow you to put TMPDIR somewhere other than $HOME (say, local /tmp if $HOME is on NFS), to keep track of TMPDIRs on a host-by-host basis, to hide the number of files and last access time of $TMPDIR, etc. There's also an ancillary script designed to keep pruning tools like 'tmpwatch' (frequently found on Linux systems) from removing $TMPDIR while you're logged in, and to warn you via multiple channels if something is amiss with your temp dir. Look for bastille-tmpdir.sh, bastille-tmpdir.csh, and bastille-tmpdir-defense.sh (the anti-'tmpwatch' tool). bastille-tmpdir.* go in /etc/profile.d where many systems will run them at login time (via /etc/bashrc or /etc/csh.login scanning /etc/profile.d) bastille-tmpdir-defense.sh goes in /etc. All three should be mode 0755. These apps will be optional in the soon-to-be-release Bastille 1.2.0 hardening tool for Red Hat and Mandrake Linux distributions. I've only tested the scripts under Linux, but they should be fairly portable. Your feedback would be most appreciated. It's nice that apps let you pick your own preferred temp space ($HOME in some cases is a poor choice), but it's a shame that some apps *need* you to do so to behave safely. :-( -Peter
Quick Analysiss of the recent crc32 ssh(d) bug
1. Abstract
---
This article discusses the recently discovered security hole in the
crc32 attack detector as found in common ssh packages like OpenSSH and
derivates using the ssh-1 protocoll. There is a possible overflow during
assignemnet from 32bit integer to 16bit wide one leading to unmasked
hash table offsets.
In this article I will try to show how:
a) exploit the crc32 hole to gain remote access to accounts without
providing any password, assuming remote sshd allows empty passwords
b) change login-uid if valid account on the remote machine exists.
I'm aware about the wide consequences arising form this disclosure and
possibly some people will hate me because I wrote this, but after you
have read this article, you will see that the exploitation is really
hard and tricky but on the other hand interessting. I think that the
impact of the crc32 hole is greater than the recent bind bug. I'm not
responsible for any damage resulting from this code, if you use this on
your own.
The exploit code is a set of patches to openssh-2.1.1, but of course one
may want to put the needed routines into one code file.
Note: this is neither a typical buffer overflow exploit (shell code) nor
a format string exploit :-)
2. Details
--
Lets look at the vulnerable code in deattack.c. I will derive few
conclusions about exploitation of the deattack code here.
Original deattack.c code taken from OpenSSH-2.1.1, interessting
locations are marked with [n]:
int
detect_attack(unsigned char *buf, u_int32_t len, unsigned char *IV)
{
static u_int16_t *h = (u_int16_t *) NULL;
static u_int16_t n = HASH_MINSIZE / HASH_ENTRYSIZE;
register u_int32_t i, j;
u_int32_t l;
register unsigned char *c;
unsigned char *d;
if (len (SSH_MAXBLOCKS * SSH_BLOCKSIZE) ||
len % SSH_BLOCKSIZE != 0) {
fatal("detect_attack: bad length %d", len);
}
[1]
for (l = n; l HASH_FACTOR(len / SSH_BLOCKSIZE); l = l 2)
;
if (h == NULL) {
debug("Installing crc compensation attack detector.");
[2] n = l;
h = (u_int16_t *) xmalloc(n * HASH_ENTRYSIZE);
} else {
if (l n) {
n = l;
h = (u_int16_t *) xrealloc(h, n * HASH_ENTRYSIZE);
}
}
if (len = HASH_MINBLOCKS) {
for (c = buf; c buf + len; c += SSH_BLOCKSIZE) {
if (IV (!CMP(c, IV))) {
if ((check_crc(c, buf, len, IV)))
return (DEATTACK_DETECTED);
else
break;
}
for (d = buf; d c; d += SSH_BLOCKSIZE) {
if (!CMP(c, d)) {
if ((check_crc(c, buf, len, IV)))
return (DEATTACK_DETECTED);
else
break;
}
}
}
return (DEATTACK_OK);
}
memset(h, HASH_UNUSEDCHAR, n * HASH_ENTRYSIZE);
if (IV)
h[HASH(IV) (n - 1)] = HASH_IV;
for (c = buf, j = 0; c (buf + len); c += SSH_BLOCKSIZE, j++) {
[3] for (i = HASH(c) (n - 1); h[i] != HASH_UNUSED;
i = (i + 1) (n - 1)) {
if (h[i] == HASH_IV) {
if (!CMP(c, IV)) {
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
[4] } else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE)) {
if (check_crc(c, buf, len, IV))
return (DEATTACK_DETECTED);
else
break;
}
}
[5] h[i] = j;
}
return (DEATTACK_OK);
}
[2] as wee see here, a 32bit int value is assigned to 16bit wide only
one. Bad things happen, if n is assigned a (truncated) value 0, because
the value of n-1, where nwould expand to 32bit before the calculation is
made is used as bit mask for following hash table operation [3]. Because
l is computed to be a power of 4 in [1], we do not need to know the
exact value for the len argument of detect_attack. We will end with n
beeing exactly 0 if len is big enough. The overflow happens at exactly
LEN = (16384 / HASH_FACTOR) * SSH_BLOCKSIZE which is 87381.
So now we know how to set n to 0. Simply send a ssh1 packet with
Re: SSH1 key recovery patch
Hello!
On Wed, Feb 14, 2001 at 05:35:13AM +0100, Ivn Arce wrote:
In light of the recent posts to bugtraq concerning the
CORE SDI advisory that describes the SSH1 session
key recovery vulnerability a few things needs to be
noted:
(...)
The rationale for the above fix is to regenerate the key whenever
a RSA operation failed - a symptom of an attacker trying to
execute the key recovery attack- this does not close the information
leakage in the ssh server (namely the existence of an oracle that can
be used to infer a session key) but it does make IMPOSSIBLE to
exploit it.
The patch intends to limit the key regeneration rate to
at most one regeneration per minute, in order to prevent
a DoS.
(...)
Wouldn't it be much easier and less error prone to actually disable the
oracle, which is the real problem leading to the attack, instead of all
this key regeneration stuff?
quote from the original attack description:
Notice that the calls to the function fatal() can be used as the
needed oracle.
Successful negotiation of a session key will end with
the reception of a SSH_SMSG_SUCCESS packet at the client. A failure
will end with the connection being shutdown due to the calls to the
fatal() function from within the rash_private_decrypt() function.
So all you have to do is to always do both RSA operations, record a
failure of the first but call fatal() only after the second. Or did I
miss something?
Regards
Johannes
The following patch is UNTESTED and supplied only to make myself clear.
--- rsaglue.c.orig Tue Feb 20 11:20:21 2001
+++ rsaglue.c Tue Feb 20 11:23:21 2001
@@ -238,11 +238,12 @@
/* Decrypt input using the private key. Output will become a 256 bit value. */
-void rsa_private_decrypt(MP_INT *output, MP_INT *input, RSAPrivateKey *key)
+int rsa_private_decrypt(MP_INT *output, MP_INT *input, RSAPrivateKey *key)
{
MP_INT aux;
unsigned int len, i;
unsigned char *value;
+ int success;
rsa_private(output, input, key);
@@ -263,8 +264,7 @@
}
mpz_clear(aux);
- if (value[0] != 0 || value[1] != 2)
-fatal("Bad result from rsa_private_decrypt");
+ success == (value[0] == 0 value[1] == 2);
for (i = 2; i len value[i]; i++)
;
@@ -272,6 +272,9 @@
xfree(value);
mpz_mod_2exp(output, output, 8 * (len - i - 1));
+
+ return success;
+
}
#endif /* RSAREF */
--- rsa.h.orig Tue Feb 20 11:38:04 2001
+++ rsa.h Tue Feb 20 12:21:50 2001
@@ -111,6 +111,6 @@
RandomState *state);
/* Performs a private key decrypt operation. */
-void rsa_private_decrypt(MP_INT *output, MP_INT *input, RSAPrivateKey *key);
+int rsa_private_decrypt(MP_INT *output, MP_INT *input, RSAPrivateKey *key);
#endif /* RSA_H */
--- sshd.c.orig Tue Feb 20 11:20:12 2001
+++ sshd.c Tue Feb 20 12:43:54 2001
@@ -1553,23 +1553,29 @@
larger modulus first). */
if (mpz_cmp(sensitive_data.private_key.n, sensitive_data.host_key.n) 0)
{
+ int rok1, rok2;
/* Private key has bigger modulus. */
assert(sensitive_data.private_key.bits =
sensitive_data.host_key.bits + SSH_KEY_BITS_RESERVED);
- rsa_private_decrypt(session_key_int, session_key_int,
- sensitive_data.private_key);
- rsa_private_decrypt(session_key_int, session_key_int,
- sensitive_data.host_key);
+ rok1 = rsa_private_decrypt(session_key_int, session_key_int,
+sensitive_data.private_key);
+ rok2 = rsa_private_decrypt(session_key_int, session_key_int,
+sensitive_data.host_key);
+ if (!(rok1 rok2))
+ fatal("Bad result from rsa_private_decrypt");
}
else
{
+ int rok1, rok2;
/* Host key has bigger modulus (or they are equal). */
assert(sensitive_data.host_key.bits =
sensitive_data.private_key.bits + SSH_KEY_BITS_RESERVED);
- rsa_private_decrypt(session_key_int, session_key_int,
- sensitive_data.host_key);
- rsa_private_decrypt(session_key_int, session_key_int,
- sensitive_data.private_key);
+ rok1 = rsa_private_decrypt(session_key_int, session_key_int,
+sensitive_data.host_key);
+ rok2 = rsa_private_decrypt(session_key_int, session_key_int,
+sensitive_data.private_key);
+ if (!(rok1 rok2))
+ fatal("Bad result from rsa_private_decrypt");
}
/* Compute session id for this session. */
Re: Adcycle 0.78b Authentication
Neil K [EMAIL PROTECTED] writes:
Anyways how to patch?? well you could parse out the following character from *all
the user defined fields: '.
Half-assed workaround. The correct fix is to modify the call to
$dbh-prepare() as follows:
$sth = $dbh-prepare("SELECT * FROM login WHERE pid='$mycookpid'
agent='$agent' ORDER BY stime DESC");
$sth = $dbh-prepare("SELECT * FROM login WHERE pid=" .
$dbh-quote($mycookpid) .
" agent =" .
$dbh-quote($agent) .
" ORDER BY stime DESC");
"I'm always Frank and Ernest with the ladies,
Frank in New York, Ernest in Boston"
--quoted from some film i watched last night
Samuel L. Jackson to Larry King in _The Long Kiss Goodnight_ - the
correct quote is "I'm always frank and earnest with women. Uh, in New
York I'm Frank, and in Chicago I'm Ernest."
DES
--
Dag-Erling Smrgrav - [EMAIL PROTECTED]
[CryptNET Advisory] pgp4pine-1.75-6 - expired public keys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
- --
CryptNET Security Advisory
http://www.cryptnet.net/
Advisory Type: Privacy - Programmatic Error
Synopsis: pgp4pine may fail to identify expired public keys
Issue Date: 2001.02.20
Program:pgp4pine-1.75-6 - http://pgp4pine.flatline.de/
Related Programs: Gnu Privacy Guard (GnuPG) Version 1.0.4
Pine Version 4.2.1
Maintainer Response:Attempts to contact the maintainer of the pgp4pine
package where unsuccessful.
- --
1. Executive Summary
pgp4pine is a program which is used to interface various PGP implementations
with the popular Pine mail reading package. Version 1.75-6 of pgp4pine fails
to properly identify expired keys when working with the Gnu Privacy Guard
program (GnuPG). This failure may result in the transmission of sensitive
information in clear text across the network.
2. Problem Description
Version 1.75-6 of pgp4pine does not include code to check if public keys
are expired when loading keys from the GnuPG openPGP implementation. If a
user has an expired public key in their keyring and attempts to encrypt a
message to a recipient with that expired public key, pgp4pine will fail to
recognize that the key is expired. pgp4pine will then issue a command to
GnuPG to encrypt the email message with the expired key. The encryption
will not be successful, GnuPG will return an error message due to the
invalid key. pgp4pine will not detect the error which occurred when
encrypting the text and will return program flow control to Pine. Pine
will then transmit the message in the clear. No notice that an error
occurred will be provided to the user by pgp4pine.
To duplicate the error on the command line:
bash$ pgp4pine -e -i /tmp/in.tmp -o /tmp/out.tmp -r (*R)
* Where R is a recipient with an expired public key in your keyring.
3. Solution
A patch, written by V. Alex Brennen, has been provided with this advisory.
The patch consists of code modifications which allow pgp4pine to recognize
and ignore expired keys when working with GnuPG.
4. About This Advisory
This advisory was produced as part of the CryptNET Free Cryptography
Auditing Project. CryptNET is a group working on the development of
Free Software cryptographic solutions. As part of its mission,
CryptNET has undertaken The Free Cryptography Auditing Project. The
project is an effort to audit some of the more popular free software
cryptographic programs licensed under the GNU General Public License.
If you would like to become involved in this project, please see the
CryptNET web site.
John Sheehy, an IBM certified specialist with e-techservices.com
(http://www.e-techservices.com/), assisted with the discovery and
identification of this bug.
- --
[ENC: Patch]
- --
diff -urN pgp4pine-1.75/pgp4pine/keyrings.c vab.pgp4pine-1.75/pgp4pine/keyrings.c
- --- pgp4pine-1.75/pgp4pine/keyrings.c Fri Aug 18 09:24:45 2000
+++ vab.pgp4pine-1.75/pgp4pine/keyrings.c Mon Feb 12 21:03:09 2001
@@ -449,22 +449,36 @@
if (strchr(buf,':') != NULL) {
strncpy(keyType,getItem(buf,':',1),3);
lineType = 0;
- - if (strcmp(keyType,"sec") == 0) lineType = 1; /*
secret line... */
- - if (strcmp(keyType,"pub") == 0) lineType = 2; /*
public key */
- - if (strcmp(keyType,"uid") == 0) lineType = 4; /*
user id*/
- -
+/*
+The letter e in the second field of the colon
+delimited GnuPG
+output denotes that gpg asserts that the
+trust on this item
+has expired (perhaps as the result of an
+expired openPGP type
+0x13 or 0x18 signature packet). If this line
+denotes a public
+key, GnuPG will not function with this key.
+So, we should
+return with out adding it to the list. We
+shouldn't check
+expiration ourselves because GnuPG is the
+final authority.
+ - V. Alex Brennen, CryptNET FCAP
+[http://www.cryptnet.net/]
+2001.02.13.01.13.47
+*/
+strncpy(tmpString,getItem(buf,':',2),1);
+
Re: AUTORUN Vulnerability - Round 2
David LeBlanc replied to Nelson Brito: When Domain Admin mount the user's shared then he'll execute the "arbitary code". This isn't true. Or at least it needs clarification. Let's say that you have a share, \\evilserver\nastytrojans. Now I as an admin access that share somehow. What happens depends on how I access it. "mount" is not a precise term, as there are many possible ways to access a remote share - you can assign a drive letter to it or not, and you could browse the share using a command line (for example, a batch file), or you could use Explorer. So if you are going to say that something happens when an admin accesses the share, you have to specify how this is done. If I do this: snip Now say I go to Explorer, and type in the path \\evilserver\nastytrojans, snip OK, now I try the following - snip Now, I have just tested the exact same thing remotely (while logged in as snip Also, for good measure, I have tried: snip In short -- all which failed... So apparently (at least on Win2k), there are several ways for me to access a share that has an autorun.exe and autorun.inf that I have verified to work (just popped the CD in and out, it ran), and I cannot seem to get it to work using every way I know how an admin might access the share. Perhaps the problem could be specific to NT 4.0 systems, or it could be that I am missing something. In fact, I just copied these files to a local hard drive, and it still did not fire. It seems that it only works for removable media on my systems (and then only when I remove and reinsert the media). I don't have any NT 4.0 systems currently running on my home network, so it wasn't practical to do a full test matrix. snip I can't easily re-test all this just now either, but last time I posted on this subject explaining all the ways it failed, someone replied pointing out I had not tried double-clicking the icon representing the mapped drive in the right panel of the "real" Explorer interface (and I think I had already pointed out that it seemed to work fine if you double-clicked the drive icon in the "simple" Explorer interface that is the default for My Computer...) Did you try those options? Also, note from MS: http://msdn.microsoft.com/library/psdk/shellcc/shell/Shell_basics/Autoplay_reg.htm Normally, AutoRun starts automatically, but it can also be started manually. If the device meets the criteria listed above, the drive letter's context menu will include an AutoPlay command. To run AutoRun manually, either right-click the drive icon and select AutoPlay from the context menu or double-click the drive icon. If the drivers are not AutoRun-compatible, the context menu will not have an AutoPlay item and AutoRun can not be started. AutoRun-compatible drivers are provided with some floppy disk drives, as well as some other types of removable media such as Compact Flash cards. AutoRun also works with network drives that are mapped to a drive letter with Windows Explorer or mounted with the Microsoft Management Console (MMC). As with mounted hardware, a mounted network drive must have an Autorun.inf file in its root directory, and must not be disabled through the registry. -- Nick FitzGerald Computer Virus Consulting Ltd. Ph/FAX: +64 3 3529854
Re: Adcycle 0.78b Authentication
Half-assed workaround. The correct fix is to modify the call to
$dbh-prepare() as follows:
$sth = $dbh-prepare("SELECT * FROM login WHERE pid='$mycookpid'
agent='$agent' ORDER BY stime DESC");
$sth = $dbh-prepare("SELECT * FROM login WHERE pid=" .
$dbh-quote($mycookpid) .
" agent =" .
$dbh-quote($agent) .
" ORDER BY stime DESC");
Actually the safe way would be to:
$sth = $dbh-prepare("SELECT * FROM login WHERE pid = ? AND agent = ? ORDER BY
stime DESC");
$sth-execute($mycookpid, $agent);
By using placeholders, your scalars can contain anything you like, without
having malicious side effects.
Greetings,
Kenneth van Grinsven
Re: Multi format string bugs in IPAD x.x ftp server
Eric Fitzgerald wrote: If I'm reading this correct. This appears to be format string bugs in your FTP client. Not in the server (notice the seg fault took you too your prompt) Connected to xxx.xxx.xxx.xxx. 220 xxx.xxx.xxx.xxx FTP server (IPAD 2.52) ready snip ftp site %s%s%s%s%s%s%s%s%s%s%s%s%s%s Segmentation fault [diab@epuj diab]$ Eric is right. I tested an IPAD 2.52 system with a linux ftp client and saw the same results. When using the FreeBSD default ftp client I got these results: 220 xxx.xxx.xxx.xxx FTP server (IPAD 2.52) ready at Wed Feb 21 09:18:41 2001 Name (xxx:xxx): anonymous 331 Anonymous logins ok. Please enter your e-mail address as password. Password: 230 User anonymous logged in. Remote system type is MSDOS. ftp site %x%x%x%x%x%x%x%x%x%x%x 500 Unknown command 'site %x%x%x%x%x%x%x%x%x%x%x' ftp site %s%s%s%s%s%s%s%s%s%s%s%s%s%s 500 Unknown command 'site %s%s%s%s%s%s%s%s%s%s%s%s%s%s' ftp site %p%p 500 Unknown command 'site %p%p' ftp site %c%c%c%c 500 Unknown command 'site %c%c%c%c' For those who don't know what an IPAD is, it's an all-in-one internet server made by eSoft that runs on MS-DOS. It has a badly non-compliant DNS server that can't receive replies bigger than 512 bytes, can't set the aa flag on NS records, and refuses to resolve any host with IPv6 information in it's dns reply. John Edwards
