Re: BugTraq: EFS Win 2000 flaw
On Fri, 19 Jan 2001, Russ wrote: To the best of my knowledge, Peter Guttman(sp?) has demonstrated for years now that there is no form of over-writing which makes any substantial difference to the ability to recover previously written data from a computer hard disk. My understanding of current "high security" standards wrt the re-use of disks which previously contained classified materials is that they only be re-used in similarly classified systems, or, are destroyed beyond any form of molecular reconstruction (e.g. melted). I see a big difference in being able to recover some files by simply booting to a different OS vs. having to break out the electron microscope and manually piece bits together. I could boot DOS or Linux to read a deleted file... I don't think I'd be able to find someone who could read the bits from 3 writes ago off of a physical disk surface for me... unless you gave me a huge amount of time and money. If the problem does exist as described... the possibility that a government forensics lab might recover some data is no exucse for not handling temp files properly for EFS. Ryan
Re: BugTraq: EFS Win 2000 flaw
To the best of my knowledge, Peter Guttman(sp?) has demonstrated for years now that there is no form of over-writing which makes any substantial difference to the ability to recover previously written data from a computer hard disk. Guttman's paper, "Secure Deletion of Data from Magnetic and Solid-State Memory" (available at http://www-tac.cisco.com/Support_Library/field_alerts/fn13070.html ) has become something of a classic, and for good reason: It's absolutely fascinating reading, describing in detail what most of us suspected and some of us never imagined. The paper, however, is five years old, and quite frankly needs to be understood in that context. Now, I'm *not* saying that Guttman's points are flawed, just that it's likely that the mechanisms used to recover data from 300 Megabyte drives probably don't scale to 80 Gigabyte disks using GMR(Gigantic Magnetoresistance) technology. The extra surface area and analog bit density used to divine past generations of data has almost certainly been exploited in the 16x explosion in data density since Guttman's paper was written. My *guess*, however, is that as drive densities have increased, the requirements for more and more advanced error correction(to increase yields on platters with miniscule deformities) has led to greater redundancy and increased platter space to entirely redundant--and reconstructable--information Furthermore, it's impossible that drive scanning technology hasn't advanced in sync with drive capacity--the bottom line is, somebody needed to design the sensors to work out the kinks from each generation of disk. Companies like OnTrack(who, incidentally, worked very well for me) have made rather successful businesses of proven what's gone is not necessarily gone. So essentially, Guttman was right, and Guttman is probably still right. But the technologies used to recover deleted data has probably advanced just as much as the technology used to store the data in the first place. My understanding of current "high security" standards wrt the re-use of disks which previously contained classified materials is that they only be re-used in similarly classified systems, or, are destroyed beyond any form of molecular reconstruction (e.g. melted). Exactly. It is the job of the medium to store information. It is the job of the incinerator to delete it. Violation of the barriers between establishing functionality and enforcing security leads to systems that allow too much access to an unstable service. So to suggest that your perceived EFS flaw can be resolved by over-writing is naive. The only solution is to encrypt in memory or use some removable partition as the temp space. Russ, you're absolutely correct about the need for memory encryption, though removable media has equivalent risks(with the exception of possibly being more conveniently incinerated). The correct behavior is for a disk to never receive anything that gives it plaintext-equivalent access to any of the actual information contained within the encrypted data. That means no decryption keys ever get written, no passwords get saved, and most importantly, *no plaintext data gets stored, not even "temporarily"*. The moment an "Encrypted File System" writes a plaintext version of the data to the disk, all is lost--whether or not an apparently laughable delete(really, "dab white-out on the page number on the index in the back of the book) operation is actually carried out. Lets not forget--an encrypted file system exists for *no other reason* but to resist attack. Encryption does not add speed. It does not add stability. It does not add anything *but* resistance against an attacker who lacks the key material. If Rickard's analysis is correct--something that should be independently verified--EFS offers attackers a rich array of simple attacks that do not require discovery of the key material. You can draw your own conclusions from that. Yours Truly, Dan Kaminsky Cisco Systems, Inc. http://www.doxpara.com
Re: ICMP fragmentation required but DF set problems.
PMTU discovery is used by TCP (primarily if not exclusively). Isn't it possible to 1. check TCP sequence numbers in ICMP frag. needed messages generated as a response to a TCP datagram (in the same way they should be checked on any ICMP dest. unreachable to prevent a trivial DoS), 2. disregard any other ICMP frag. needed message? That's how we do it in OpenBSD in the IPv4 case. Since the ICMP has to include the IP packet + 8 bytes from the following header, you can just look up any tcb that corresponds to the quoted TCP header in the ICMP need fragment message. If you dont have such a tcb, you ignore the ICMP message. This basically reduces the attack to an adversary who can sniff your connection, but that would allow her to do all kinds of other things to your TCP connection. IPv6 is another case though. Here you have mandatory PMTU for all protocols. Niels.
Reply to EFS note on Bugtraq
Due to some mail trouble, I'm manually forwarding this note. The signature should check out. Ryan From: Microsoft Security Response Center Sent: Monday, January 22, 2001 2:17 PM To: '[EMAIL PROTECTED]' Cc: Microsoft Security Response Center Subject:Re: BugTraq: EFS Win 2000 flaw -BEGIN PGP SIGNED MESSAGE- Hi All - While EFS does indeed work as Rickard discusses, this is not new information. For instance, "Encrypting File System for Windows 2000" (http://www.microsoft.com/WINDOWS2000/library/howitworks/security/encr ypt.asp, p 22) notes the following: "EFS also incorporates a crash recovery scheme whereby no data is lost in the event of a fatal error such as system crash, disk full, or hardware failure. This is accomplished by creating a plaintext backup of the original file being encrypted or decrypted. Once the original is successfully encrypted or decrypted, the backup is deleted. NOTE: Creating a plaintext copy has the side-effect that the plaintext version of the file may exist on the disk, until those disk blocks are used by NTFS for some other file." The plaintext backup file is *only* created if an existing plaintext document is coverted to encrypted form. If a file is created within an encrypted folder, it will be encrypted right from the start, and no plaintext backup file will be created. Microsoft recommends this as the preferred procedure for using EFS to protect sensitive information. "Encrypting File System for Windows 2000", page 22, makes this recommendation: "... it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc." Even if the plaintext backup file were not created, it would still be a bad idea to create a sensitive file in plaintext and then encrypt it later. Many common operations, such as adding data to or removing data from a file, compressing and decompressing a file, defragmenting a drive, or opening a file using an application that creates temporary files, can result in plaintext being left on the drive. It is simply not feasible for any software package to be able to track down and erase all the plaintext "shreds" that may have been created during the file's plaintext existence. The only way to ensure that there is no plaintext on the drive is to encrypt the file right from the start. Nevertheless, we are investigating this issue to see whether there are improvements we can make. No matter what the solution, it will still be better for customers to create sensitive files encrypted from the start; however, we believe it may be possible to prevent the plaintext backup file from being retained on the drive. Regards, Scott Culp Security Program Manager Microsoft Security Response Center - - -Original Message- From: Rickard Berglind [EMAIL PROTECTED] Sent: Fri, 19 Jan 2001 12:29:50 +0100 To: [EMAIL PROTECTED] Subject: BugTraq: EFS Win 2000 flaw I have found a major problem with the encrypted filesystem ( EFS ) in Windows 2000 which shows that encrypted files are still very available for a thief or attacker. The problem comes from how EFS works when the encryption is done. When a user marks a file for encryption a backup-file, called efs0.tmp, will be created. When the copy is in place the orginal file will be deleted and then recreated, now encrypted, from the efs0.tmp- file. And finally, when the new encrypted file is succesfully created, the temporary-file ( which will never be shown in the user interface ) will be deleted as well. So far, so good. The only file remaining is the one which is encrypted. But the flaw is this: the temporary-file is deleted in the same way any other file is "deleted" - i.e. the entry in the $mft is marked as empty and the clusters where the file was stored will be marked in the $Bitmap as available, but the psysical file and the information it contains will NOT be deleted. The information in the file which the user have encrypted will be left in the backup file efs0.tmp in total plaintext on the surface of the disk. When new files are added to the partition will they gradually overwrite the secret information, but if the encrypted file was large - the information could be left for months. So how can this be exploited ? If someone steals a laptop or have psysical access to the disk it will be easy to use any low level disk editor to search for the information. For example, the Microsoft Support Tool "dskprobe.exe" works fine for locating old efs0.tmp-files and read information, in plain-text, that the user thought was safe. In my opinion there should be a function in the EFS which physically overwrites the efs0.tmp at least once to make it a lot harder for an
[Security Announce] MDKSA-2001:014 - MySQL and php update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Linux-Mandrake Security Update Advisory Package name: MySQL and php Date: January 22nd, 2001 Advisory ID:MDKSA-2001:014 Affected versions: 7.2 Problem Description: A security problem exists in all versions of MySQL after 3.23.2 and prior to 3.23.31. The problem is that the SHOW GRANTS command could be executed by any user making it possible for anyone with a MySQL account to get the crypted password from the mysql.user table. The new 3.23.31 version fixes this. Due to library changes, the previously announced PHP update (MDKSA-2001:013) has been updated as well so that the php-mysql module supports this new version of MySQL. It also corrects the upgrade scripts in the package, however you will still need to verify that PHP support is enabled in your /etc/httpd/conf/httpd.conf Apache configuration file and verify that the installed modules are uncommented in your /etc/php.ini file. Please verify the update prior to upgrading to ensure the integrity of the downloaded package. You can do this with the command: rpm --checksig package.rpm You can get the GPG public key of the Linux-Mandrake Security Team at http://www.linux-mandrake.com/en/security/RPM-GPG-KEYS If you use MandrakeUpdate, the verification of md5 checksum and GPG signature is performed automatically for you. Linux-Mandrake 7.2: 06ccef6a0a68e631847b10d1d30a79f9 7.2/RPMS/MySQL-3.23.31-1.1mdk.i586.rpm c17be32deca79950d9a61a78442dfe8e 7.2/RPMS/MySQL-bench-3.23.31-1.1mdk.i586.rpm 748534a09c309bdc02689497f0f0e178 7.2/RPMS/MySQL-client-3.23.31-1.1mdk.i586.rpm 856f12fe37b031db9e1fa267fe5fc5fa 7.2/RPMS/MySQL-devel-3.23.31-1.1mdk.i586.rpm 3aef6e7d31fc0d2fc6d561b32a46ba94 7.2/RPMS/MySQL-shared-3.23.31-1.1mdk.i586.rpm 3ae3695872918ca460de8a54946b0c08 7.2/SRPMS/MySQL-3.23.31-1.1mdk.src.rpm fe069a4995c82e7f1548f2a6a2d806f6 7.2/RPMS/mod_php-4.0.4pl1-1.2mdk.i586.rpm 416ad3191b034c53a18ec38ec100d831 7.2/RPMS/php-4.0.4pl1-1.2mdk.i586.rpm 1ec671999473d7b800bc2b24ad95625d 7.2/RPMS/php-dba_gdbm_db2-4.0.4pl1-1.2mdk.i586.rpm 1491a462a960192dbcb41f873aab5e6d 7.2/RPMS/php-devel-4.0.4pl1-1.2mdk.i586.rpm 25e3ba4887b2bf90580df6402d07306b 7.2/RPMS/php-gd-4.0.4pl1-1.2mdk.i586.rpm f9e2732a884495a4cd8d9f812db0146e 7.2/RPMS/php-imap-4.0.4pl1-1.2mdk.i586.rpm 22fa6e8b8ab089fd2f1ff4f782df7d63 7.2/RPMS/php-ldap-4.0.4pl1-1.2mdk.i586.rpm 27fef2a3d3cbcb6053e6c8f5e1680faa 7.2/RPMS/php-manual-4.0.4pl1-1.2mdk.i586.rpm 854e5f9b837b998dad8f523a0fffa6f0 7.2/RPMS/php-mysql-4.0.4pl1-1.2mdk.i586.rpm f25f06f33133c126c592929a5b54f796 7.2/RPMS/php-pgsql-4.0.4pl1-1.2mdk.i586.rpm 61dbb4df3f9993cb742aaa59306e9cd1 7.2/RPMS/php-readline-4.0.4pl1-1.2mdk.i586.rpm 70ac8cd0cf8808ce8cbd9546d3a0dac9 7.2/SRPMS/php-4.0.4pl1-1.2mdk.src.rpm To upgrade automatically, use MandrakeUpdate. If you want to upgrade manually, download the updated package from one of our FTP server mirrors and upgrade with "rpm -Fvh *.rpm". You can download the updates directly from one of the mirror sites listed at: http://www.linux-mandrake.com/en/ftp.php3. Updated packages are available in the "updates/[ver]/RPMS/" directory. For example, if you are looking for an updated RPM package for Linux-Mandrake 7.2, look for it in "updates/7.2/RPMS/". Updated source RPMs are available as well, but you generally do not need to download them. Please be aware that sometimes it takes the mirrors a few hours to update. You can view other security advisories for Linux-Mandrake at: http://www.linux-mandrake.com/en/security/ If you want to report vulnerabilities, please contact [EMAIL PROTECTED] Linux-Mandrake has two security-related mailing list services that anyone can subscribe to: [EMAIL PROTECTED] Linux-Mandrake's security announcements mailing list. Only announcements are sent to this list and it is read-only. [EMAIL PROTECTED] Linux-Mandrake's security discussion mailing list. This list is open to anyone to discuss Linux-Mandrake security specifically and Linux security in general. To subscribe to either list, send a message to [EMAIL PROTECTED] with "subscribe [listname]" in the body of the message. To remove yourself from either list, send a message to [EMAIL PROTECTED] with "unsubscribe [listname]" in the body of the message. To get more information on either list, send a message to [EMAIL PROTECTED] with "info [listname]" in the body of the message. Optionally, you can use the web interface to subscribe to or
Re: BugTraq: EFS Win 2000 flaw
Russ, To the best of my knowledge, Peter Guttman(sp?) has demonstrated for years now that there is no form of over-writing which makes any substantial difference to the ability to recover previously written data from a computer hard disk. You're correct that Peter Gutmann (note spelling) has shown that you can recover anything, given enough time money, from an erased disk. It's not outrageously expensive or difficult, but it's certainly non-trivial. But I don't think that's what the point was. I think the point was that the data is NEVER overwritten on disk. That's much easier than Peter's schemes for retrieving data. You don't need any special hardware to do it, unlike Peter's schemes. [None of which is to take away from Peter's excellent research...] My understanding of current "high security" standards wrt the re-use of disks which previously contained classified materials is that they only be re-used in similarly classified systems, or, are destroyed beyond any form of molecular reconstruction (e.g. melted). That's generally true, although it depends on how classified the data was. Disks containing Secret data could be reused for unclassified work with sufficient overwriting, but Top Secret was never reusable. That was a few years ago; it may have changed. So to suggest that your perceived EFS flaw can be resolved by over-writing is naive. The only solution is to encrypt in memory or use some removable partition as the temp space. Disagree. Security isn't an absolute. Overwriting makes it significantly harder to recover deleted data, although certainly not impossible. It's enough of an impediment that it may encourage the attacker to go read someone else's disk. And that may be enough, depending on the sensitivity of the data. --Jeremy
[SAFER] Security Bulletin 010123.EXP.1.10
__ S.A.F.E.R. Security Bulletin 010123.EXP.1.10 __ TITLE: Buffer overflow in Lotus Domino SMTP Server DATE : January 23, 2001 NATURE : Remote execution of code, Denial-of-Service AFFECTED : Lotus Notes/Domino 5 (up to and including 5.05) PROBLEM: Buffer overflow exists in Lotus Domino SMTP server, which can lead to Denial-of-Service or remote execution of code in context of user which SMTP server is running as. DETAILS: Lotus Domino/Notes server has a 'policy' feature, which is used to define relaying rules. However, improper bounds checking allow remote user to overflow the buffer and execute arbitrary code. If policy is enabled to check for domain name it is possible to trigger the overflow. -- cut -- #!/usr/bin/perl $req="a" . "%A"x200 . "A"x600 . "%allowed.domain.com\@allowed.domain.com"; print "ehlo foo\nmail from: blah\@example.com\nrcpt to:$req\ndata\nfoo\n.\nquit\n"; -- cut -- Modify the 'allowed.domain.com' to the domain name which Notes SMTP server is accepting mail for (check policies). Pipe the output through the netcat (for example), and you should be able to crash the remote server. Further examination of the crash demonstrates that we are able to overwrite contents of EIP register as well, which is the proof of remote code execution possibility. To recover from the crash, you might be required to remove 'log.nsf' and/or 'mail.box' files afterwards (due to corruption) - be careful while testing for this problem. This vulnerability has been confirmed on Notes release for Linux and Windows. Others platforms have not been tested. FIXES: Lotus has been informed about this problem on November 2nd, 2000. Mail has been 'silently ignored', but the problem has eventually been fixed in 5.0.6 release, and it has been confirmed in a response to our attempt to inform them about the problem again on January 8th. Fix details are available at: http://www.notes.net/r5fixlist.nsf/6d4eae9850a5c2c28525690400551b57/5eea8322c479de968525697d00737ad5?OpenDocument Lotus says that it was 'potential denial of service attack'. However, it is more serious than DoS - code execution is possible. All users that use policy feature should upgrade to Notes/Domino 5.0.6. CREDITS: Fyodor Yarochkin [EMAIL PROTECTED] Vanja Hrustic [EMAIL PROTECTED] Thomas Dullien [EMAIL PROTECTED] Emmanuel Gadaix [EMAIL PROTECTED] This advisory is also available at http://www.safermag.com/advisories/ __ S.A.F.E.R. - Security Alert For Enterprise Resources Copyright (c) 2001 The Relay Group http://www.safermag.com [EMAIL PROTECTED] __
No Subject
*** Aa explotable example of this has been found using white text. I think it's time this hits the list, wether MS likes it or not -Ben *** DHTML/CSS/web-based email Vulnerability Report: Dylan Griffiths ([EMAIL PROTECTED]) and Ben Li ([EMAIL PROTECTED]) Discovery: Ben Li Jan 15, 2001 Originally sent Jan 6, 2001 (not Jan 6, 2000) Summary: There is a bug in many 4th generation browsers that allows users of web based email to be mis-directed to unintended destinations when mail management buttons are clicked. This is due to interactions between the browser and CSS DIV tags, and the DHTML LAYER tag. Vendor contact: It would be impossible to contact every web-based email provider out there in a timely manner so those with the most users will be given priority. Microsoft, Netscape, Opera, USANet and Yahoo! were sent a preliminary copy of this report on 6 Jan 2001 since they have the largest web-based email subscriber bases and thus the most potential vulnerable users. Microsoft was the only vendor that responded interactively and has stated that they do not believe this to be an issue. The vendors were sent a second preliminary copy of this report on 14 Jan 2001 with no response from any vendors other than Microsoft. Details: A properly malformed page containing the DIV (or LAYER) tag anchors a BROKEN* clickable image (an image surrounded by A HREF=.../A) over top of the page containing other links by using a z-index of zero (effectively on top of everything else) in the style for the image. Since it is a broken image, the page is not obscured by the image, and clicks directed to links on the page will instead send the user to the page specified in the HREF for the floating image. This could be exploitable by sending crafted HTML to users of web-based email providers (such as Hotmail, ZDNet mail, etc) or possibly by sending the same email to users with email clients that render HTML. This is vulnerability could also exist in other HTML-rendering applications as well (for example, Napster, CuteMX, etc). * the SRC address for the image refers to a resource that cannot be found at that address Examples: 1. A user gets an stupid-looking (or blank) malicious mail in their web-based email. They click "delete" (or other navigation tools: forward, back, save address, etc) to delete the message, and are sent to a nasty place like goatse.cx, which is linked to by the floating image. Alternatively, the user is directed to a counterfeited page on the attacker's server asking the user to re-login or supply information asking them for verification of adulthood through a credit card number. 2. A user is logged in to Hotmail and views the message contained in the HTML code example below. Since the floating image covers the entire page (the image is 3000 by 3000 pels in our example below), they would be unable to log out or navigate from the current message by clicking elements on the page and would need to navigate out of the message using the back button (or its keyboard counterpart) or by specifying a new URL to view using the address bar. 3. A user is logged in to Hotmail and clicks the ad banner, which has a broken image positioned over it which directs the user to another site, resulting in monetary losses for Microsoft and the people advertising with the banner. Browser specifics: The presentation of links in DHTML can be very complex because of the interactions between link rendering, image rendering, page layering, other elements, and CSS. Thus different browsers are vulnerable to different variations of the exploit code below and on different web-based email sites. Additionally, some page elements (for example, form elements) may be assigned an effective Z-order of -1 in the browser (which is above the Z-order of 0 for the floating image), resulting in vulnerable image and text links but not form elements. Your mileage will vary. Internet Explorer for Windows and Mozilla are largely vulnerable because there is no easy way of turning off CSS (doing so seems to correct the issue in other browsers). Mozilla is, however, harder to trick into allowing the layer overlay to obstruct links below it. If the domain from which the image is sourced does resolve but does not contain the image file, Mozilla reduces the image to a link with the ALT text. If the domain doesn't resolve, it will use a placeholder image in its place. Opera is partially vulnerable on Hotmail (some buttons are obscured by the large image shown in the code above, others are not), and not vulnerable on ZDNet mail because of how ZDNet mail implements their buttons. ZDNet mail and Yahoo! also use frames to separate the message display frame from navigation/other frames which reduces this vulnerability to only the message display frame. Netscape 4.7 is vulnerable to both DIV and LAYER on the PC and appears to be vulnerable to
Solaris /usr/bin/cu Vulnerability
In Solaris 2.6 patch 106468-02 replaces cu in Sol 7 patch 108372-01 replaces it for gets() use. The script does SegFault in 8, but no core file... I am running 10/2000 revision and 108372 came out in may, so it's probably cool. -- hal king Unix System Group[EMAIL PROTECTED] pgp key http://web.utk.edu/~hck/hal.asc No hot dog, email.
Re: MySQL 3.23.31 Overflow [exploit] (fwd)
Hi! I got forwarded this 'exploit' of MySQL: Lus Hello... Lus Here's a exploit for this... Lus [See attached...] Lus Regardz, Lus Lus Miguel Silva aka wC Lus Member of lonoss.org and unsecurity.org Lus http://www.lonoss.org/ Lus http://www.unsecurity.org/ Lus http://www.ispgaya.pt/ Student Lus Personal WebPage at: Lus http://paginas.ispgaya.pt/~lms/ Lus Lus http://www.unsecurity.org/wC/ Lus Personal Code at: Lus www.unsecurity.org/wC/MyCode/ Lus /* Lus Linux MySQL Exploit by Luis Miguel Silva [aka wC] Lus [EMAIL PROTECTED] Lus 19/01/y2k+1 Lus Compile: Lusgcc MySQLXploit.c -o MySQLX Lus Run with: LusYou can specify the offset for the exploit passing it as the 1st arg... LusExample: ./MySQLX 0 --- this is the default offset :] Lus Advisorie: Lus [from a bugtraq email] Lus Hi, Lus all versions of MySQL 3.23.31 have a buffer-overflow which crashs the Lus server and which seems to be exploitable (ie. 4141414 in eip) Lus Problem : Lus An attacker could gain mysqld privileges (gaining access to all the Lus databases) Lus Requirements : Lus You need a valid login/password to exploit this Lus Solution : Lus Upgrade to 3.23.31 Lus Proof-of-concept code : Lus None Lus Credits : Lus I'm not the discoverer of this bug Lus The first public report was made by [EMAIL PROTECTED] via the MySQL Lus mailing-list Lus See the following mails for details Lus Regards, Lus Nicob cut I have looked at the 'exploit' and tested this against a 3.23.30 server, but it didn't work. The server gave nicely the error: - (/my/tmp) exploit 0 MySQL [all versions 3.23.31] Local Exploit by [EMAIL PROTECTED] Trying to allocate memory for buffer (130 bytes)...SUCCESS! Using address : 0x41414141 Offset: 0 Buffer Size : 130 Oh k...i have the evil'buffer right here :P So...[if all went well], prepare to be r00t... Enter password: ERROR 1064 at line 1: You have an error in your SQL syntax near '^1ÀFF ° óV Í1ÛØ@ÍèÜÿÿÿ/bin/shA' at line 1 - I can't see how this particular exploit could work, as MySQL strips all not-ASCII characters from the column name and stops as the first not-ASCII character. In other words, an exploit like this could theoretically work if the assembler code only used bytes in this region, but as this particular program didn't do that... Anyway, this is just a typical example why one should be careful of not running mysqld as root, but as it's own user. Regards, Monty
[SECURITY] [DSA-012-1] New version of micq released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-012-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 22, 2001 - Package: micq Vulnerability : remote buffer overflow Debian-specific: no PkC has reported that there is a buffer overflow in sprintf() in micq versions 0.4.6, that allows to a remote attacker able to sniff packets to the ICQ server to execute arbitrary code on the victim system. We recommend you upgrade your micq package immediately. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Potato was released for the alpha, arm, i386, m68k, powerpc and sparc architectures. Source archives: http://security.debian.org/dists/stable/updates/main/source/micq_0.4.3-4.dsc MD5 checksum: b564dd2d8e937611bd90d73096d4a138 http://security.debian.org/dists/stable/updates/main/source/micq_0.4.3.orig.tar.gz MD5 checksum: ddc011d3509d593284bf9336e0a9f829 http://security.debian.org/dists/stable/updates/main/source/micq_0.4.3-4.diff.gz MD5 checksum: f86304bdbec4d1cf86fb991fc8355f39 Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/micq_0.4.3-4_i386.deb MD5 checksum: b5a2d7327ffc35ab49a1e4f64c6f2567 Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/micq_0.4.3-4_m68k.deb MD5 checksum: a07906bae588eaec0b20974a8a871704 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/micq_0.4.3-4_sparc.deb MD5 checksum: 59d5b78bea7f4cce3ea4ca7b5b28d005 Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/micq_0.4.3-4_alpha.deb MD5 checksum: 06264f9d8a99edfcc43fac35080cc544 PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/micq_0.4.3-4_powerpc.deb MD5 checksum: fbd7bb304918dad6f59d75c5a220dd31 ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/micq_0.4.3-4_arm.deb MD5 checksum: 492b4162cc8f59c5dae6e56860ae6bfe These files will be moved into ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. For not yet released architectures please refer to the appropriate directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ . - 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 pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6bK4rW5ql+IAeqTIRAiMpAJwJSCw++1gi200ZdlN3s2dY8eiM4QCdEv1q OCg4/8B3PhZLbcmy+9zVAKg= =OUwR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[SECURITY] [DSA-015-1] New version of sash released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-015-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 23, 2001 - Package: sash Vulnerability : broken maintainer script Debian-specific: yes Versions of sash prior to 3.4-4 did not clone /etc/shadow properly which lead into readable files for anybody. This was fixed by the Debian maintainer. This package only exists in stable, so if you are running unstable you won't see a bugfix unless you use the resources from the bottom of this message to the proper configuration. We recommend you upgrade your sash package immediately. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Potato was released for the alpha, arm, i386, m68k, powerpc and sparc architectures. Source archives: http://security.debian.org/dists/stable/updates/main/source/sash_3.4-6.diff.gz MD5 checksum: f65d5dfd23acc395b99651076e8029bd http://security.debian.org/dists/stable/updates/main/source/sash_3.4-6.dsc MD5 checksum: c78f46d34405afcbaae29726dd9f8e89 http://security.debian.org/dists/stable/updates/main/source/sash_3.4.orig.tar.gz MD5 checksum: 9c631eb171371b69276ff6692100beb6 Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/sash_3.4-6_i386.deb MD5 checksum: 4273648c65527f88855887f97bb6eeab Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/sash_3.4-6_m68k.deb MD5 checksum: 7bc34c6c7b0b1f6793693853711c76ad Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/sash_3.4-6_sparc.deb MD5 checksum: 1fdadd243c5aabc329edcb880dcd2581 Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/sash_3.4-6_alpha.deb MD5 checksum: 57837ce03d6c55dad077d67cc18ed38a PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/sash_3.4-6_powerpc.deb MD5 checksum: b5bf950effb0517552e0056ce995120e ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/sash_3.4-6_arm.deb MD5 checksum: d7e3253ef764c1bb10b04caafd7b9c30 These files will be moved into ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. For not yet released architectures please refer to the appropriate directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ . - 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 pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6bNE0W5ql+IAeqTIRAgLoAJ9CohteWM4aVgKghMRRZ1JjiHcdbACfeYRe 2SKtPRjH2k9IRbcwHZ6+RIw= =OHfM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Patch for Potential Vulnerability in Oracle XSQL Servlet
Patch for Potential Vulnerability in Oracle XSQL Servlet Description: A potential security vulnerability in Oracle XSQL Servlet has been discovered when using stylesheets as URL parameters which permits the execution of arbitrary Java code on the Oracle 8.1.7.0.0 database server with elevated privileges. This vulnerability was discovered in Oracle8i, Release 8.1.7.0.0, Enterprise Edition running Oracle Internet Application Server (iAS) and XSQL Servlet, Release 1.0.0.0, on MS Windows 2000. It also exists in XSQL releases 1.0.1.0 to 1.0.3.0 on all platforms. Solution: Oracle has corrected this vulnerability in the new release of XSQL Servlet as well as provided more secure behavior by default. The new release of XSQL Servlet, Release 1.0.4.0, can be obtained from Oracle Technology Network, OTN, http://otn.oracle.com/tech/xml/xsql_servlet. A patch will also be available in the upcoming Oracle8i, Release 8.1.7.1, patch set and available for use with iAS Release 1.0.2.1. Credits: Oracle Corporation wishes to thank Georgi Guninski for discovering this vulnerability and promptly bringing it to Oracle's attention.
Re: BugTraq: EFS Win 2000 flaw
One of the advertised features of EFS was protection of data in the event of say a stolen laptop. EFS was supposed to protect against someone throwing the harddrive into another system that they did have admin access on, and circumventing the NTFS permissions in that manner. Again this issue shows that physical security is the underlying trump card. -- Correct me if I'm wrong, but the use of programs that utilize direct disk access (such as DiskProbe) is restricted to the Local Administrator account (as per http://www.microsoft.com/windows2000/guide/professional/solutions/manageme nt.asp). If an would be attacker has this kind of access, he automatically has the sufficient power (due to the existence of the recovery agent certificate, unless the computer is part of a domain (but that's another story) to decrypt any locally stored file. _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Buffer Overflow still exists in Netscape = 4.76
Hi fish stiqz, Well, after reading you first message regarding this, I tried your tool and loaded a page with 2 A's into my netscape and it crashed the same moment. Impressive. So, I decided to try this again and see, whether I could reproduce the different behavior with different sizes you wrote about. I started with 1000 A's and gradually increased it, always hitting reload after i generated a new file. And ... nothing happened. I tried hitting reload multiple times, hitting shift+reload and viewing the source and apart from the time it took to load big pages, absolutely nothing changed. When I got a file with 1M A's and still nothing happened, I loaded this file into a newly opened window and ... crash. So I tried this again and, if you first generate a page with a form that only has 1000 or so A's, then change that file to have much more A's and only hit reload (Not open a new window and open the file there, or hit Back - Forward in the history) it won't crash. Another thing to note: it crashes after loading all the A's but not before reaching End-Of-File. I'm not using a rpm but got the binary from netscape (well, I think so): $ md5sum netscape-4.76.tgz 577f4545020a6bcbd016db549fa16f61 netscape-4.76.tgz And yet two other notes: In this part of the universe netscape dies of SIGBUS and not SIGSEGV (see gdb-dump at the end of this posting) I also tried a file with 20M A's and the only thing that I noticed was a significant decrease in loading speed after loading some 34% or so. Exactly what did you do that it didn't segfault on you? In all my tests Netscape has died either as soon as the page loads or as soon as you try to go somewhere else (or reload). Maybe Frank did what I did, as my Netscape really won't die of anything when using a small file first. $ gdb netscape core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...(no debugging symbols found)... Core was generated by `netscape crash.htm'. Program terminated with signal 7, Bus error. Reading symbols from /lib/libBrokenLocale.so.1...done. Loaded symbols for /lib/libBrokenLocale.so.1 Reading symbols from /usr/X11R6/lib/libXt.so.6...done. Loaded symbols for /usr/X11R6/lib/libXt.so.6 Reading symbols from /usr/X11R6/lib/libSM.so.6...done. Loaded symbols for /usr/X11R6/lib/libSM.so.6 Reading symbols from /usr/X11R6/lib/libICE.so.6...done. Loaded symbols for /usr/X11R6/lib/libICE.so.6 Reading symbols from /usr/X11R6/lib/libXmu.so.6...done. Loaded symbols for /usr/X11R6/lib/libXmu.so.6 Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Loaded symbols for /usr/X11R6/lib/libXpm.so.4 Reading symbols from /usr/X11R6/lib/libXext.so.6...done. Loaded symbols for /usr/X11R6/lib/libXext.so.6 Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Loaded symbols for /usr/X11R6/lib/libX11.so.6 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libstdc++-libc6.1-1.so.2...done. Loaded symbols for /usr/lib/libstdc++-libc6.1-1.so.2 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 #0 0x401fca71 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x401fca71 in __kill () from /lib/libc.so.6 #1 0x8940170 in PR_ClearPendingException () #2 signal handler called #3 0x4022c68e in _IO_sgetn (fp=0x92b9700, data=0x8ebd000, n=4096) at genops.c:431 #4 0x40227c03 in _IO_fread (buf=0x8ebd000, size=1, count=4096, fp=0x92b9700) at iofread.c:42 #5 0x83d2ed1 in cache_DBDataToExtCacheDBInfoStruct () #6 0x83d3d26 in NET_ProcessFile () #7 0x83dd2d7 in NET_ProcessNet () #8 0x82ce0ab in fe_GetSecondaryURL () #9 0x4003d3a1 in XtAppProcessEvent () from /usr/X11R6/lib/libXt.so.6 #10 0x82bd5cc in fe_EventLoop () #11 0x82bffc5 in main () #12 0x401f6a5e in __libc_start_main (main=0x82be7a4 main, argc=2, argv=0xb874, init=0x827f548 _init, fini=0x894914c _fini, rtld_fini=0x4000aa20 _dl_fini, stack_end=0xb86c) at ../sysdeps/generic/libc-start.c:92 -- Henryk Pltz Gre von der Ostsee S/MIME Cryptographic Signature
Re: BugTraq: EFS Win 2000 flaw
In case anyone's interested, here's a summary of the responses I received to my incorrect assertions; I should say that I was under the honest belief that companies, such as OnTrack, made available services which could recover overwritten data at a reasonable price. I called them this morning and asked, they responded that if the data was overwritten then it was basically not possible to recover. They wouldn't say whether they did make such a service available, but the implication is clearly that its not as trivial, or inexpensive, as I believed it to be. Thanks to Ryan Russell for setting me straight on that. Frank Knobbe [EMAIL PROTECTED] pointed out that PCGuardian's Encryption Plus Hard Disk software works well on Windows 2000 and does complete disk encryption (enter password at boot to decrypted system files), solving the EFS issues posed by Rickard. Kris Kennaway [EMAIL PROTECTED] was succinct; "Don't be silly. If the file was overwritten even once then it can't be recovered in software. Not many people have access to expensive scanning equipment which can pick up residual magnetisation of the storage medium." Camillo Srs [EMAIL PROTECTED] said; "F-Secure FileCrypto does a secure delete, that is overwrite, of the original when doing an initial encryption. Nevertheless, any files created after encryption comes into effect are immediately written to disk in encrypted form, without any intermediate steps of writing temporary plaintext to disk." Roman Fischer [EMAIL PROTECTED] said; "PGPDisk creates one large file. On this file, it reads/writes the data. Thus it overwrites the same parts of the file all the time, not leaving any temp files behind (other than maybe in swap space or memory)." Its probably also interesting to note that Microsoft makes significant mention of EFS' ability to encrypt temporary files created by applications (e.g. Word), thereby protecting encrypted data from leakage, in their EFS White Paper; http://www.microsoft.com/technet/win2000/win2ksrv/technote/nt5efs.asp "EFS is integrated with the operating system so that it stops the leaking of key information to page files and ensures that all temporary copies of an encrypted file are encrypted." Note they mention "that all temporary copies of an encrypted file are encrypted", which doesn't address Rickard's observations of the plaintext copy of a file being encrypted. They also make no mention of the temporary file being created in their graphic "Figure 1 File Encryption Process" on that page. Bottom line is that my assertion was wrong that it was naive to believe that over-writing was a resolution to the problems observed by Rickard. While not assuring files couldn't be obtained, it does offer significant resistance to attack (Dan Kaminsky's phrase.) Cheers, Russ - Surgeon General of TruSecure Corporation/NTBugtraq Editor
Re: eEye Iris the Network traffic analyser DoS
This indeed is a bug in Iris 1.01 beta and it has been fixed within Iris 2.0. Iris 2.0 should be released within the next two days. All users of Iris 1.01 are being contacted and sent a url to 2.0 once it is released. The one thing to note is that someone has to actually click and view the "evil" packet in order for Iris to crash. If you simply open iris and start sniffing and receive the "evil" packet, without clicking to view it, then Iris will not crash. Thanks much to grazer for contacting us prior to posting to Bugtraq so that we could work on a fix for this problem. Signed, Marc Maiffret Chief Hacking Officer eCompany / eEye T.949.349.9062 F.949.349.9538 http://eEye.com | -Original Message- | From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of grazer | Sent: Sunday, January 21, 2001 6:27 PM | To: [EMAIL PROTECTED] | Subject: eEye Iris the Network traffic analyser DoS | | | Hi there, | | There exists a vulnerability that will cause the iris network | traffic analyser to hang. | I have included an exploit, that will demonstrate the bug, the | exploit will send a packet to the remote host, | when the remote host opens the packet (to examine it) iris will | quit, leaving an error message. | | Sincerely yours, | | Wouter ter Maat aka grazer | digit-labs information security | http://www.digit-labs.org | |
Re: Buffer overflow in bing
On Fri, Jan 19, 2001 at 08:30:01PM +0100, Pierre Beyssac wrote: On Fri, Jan 19, 2001 at 06:52:27PM +0100, Paul Starzetz wrote: The buffer overflowed is a 80 byte static local buffer: static char buf[80]; It is patched by default in FreeBSD's package collection. Here's the patch below (author: [EMAIL PROTECTED]). Actually, the patch was mine :-) revision 1.1 date: 2000/03/05 05:30:54; author: kris; state: Exp; This is a setuid root binary. sprintf()s of DNS hostnames into undersized buffers are bad. Fix this. It should also drop privileges for extra safety, but doesn't. = Kris -- NOTE: To fetch an updated copy of my GPG key which has not expired, finger [EMAIL PROTECTED] PGP signature
Re: Buffer overflow in MySQL 3.23.31
Hi, - Original Message - From: "Nicolas GREGOIRE" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 18, 2001 5:44 PM Subject: Buffer overflow in MySQL 3.23.31 Hi, all versions of MySQL 3.23.31 have a buffer-overflow which crashs the server and which seems to be exploitable (ie. 4141414 in eip) Problem : An attacker could gain mysqld privileges (gaining access to all the databases) Requirements : You need a valid login/password to exploit this Not allways, in a default instalation one can exploit like this: mysql -ustring -equery , no need for a valid database, login, nor password. Also, afaik, this can't easly be exploited just by using a "select a.(buffer).a" because buffer must be part of a valid SQL query. I didn't test it, but i supose it's true. The real danger of this flaw, i think, is the possibility of beeing exploited remotely. If there is a simple php script ( for example ), that has a sql query like "$SQL=select * from table where index=$index" ( providing that $index isn't quoted), one can exploit using somethig like: script.php?index=a.(buffer).b Solution : Upgrade to 3.23.31 Proof-of-concept code : None Credits : I'm not the discoverer of this bug The first public report was made by [EMAIL PROTECTED] via the MySQL mailing-list See the following mails for details Best regards, Joao Gouveia -- [EMAIL PROTECTED]
def-2001-06: Easycom/Safecom 10/100 Multiple DoS
== Defcom Labs Advisory def-2001-06 Easycom/Safecom 10/100 Multiple DoS Author: Peter Grndl [EMAIL PROTECTED] Release Date: 2001-01-23 == =[Brief Description]=- The Easycom/Safecom print server from I-Data International contains multiple vulnerabilites that allow a malicious user to bring down the print server. Execution of arbitrary code is also possible. =[Affected Systems]=-- - Easycom/Safecom, firmware 404.590 - Most likely older firmware revisions as well --=[Detailed Description]= The print server has a web service running on port 80 and on port 631. Both are vulnerable to a long URL request. The long URL results in a buffer overflow on the server. The effect can either be that the unit crashes or execution of arbitrary code on the server. The PrintGuide service on port 5742 will cease to respond, if you send two bursts (80 connects in each burst) of null characters to the port. The FTP service on TCP port 21 is vulnerable to data flooding. The flooding results in the unit being disconnected from the network. The web services on port 80 and port 631 are both vulnerable to long HTTP requests. An infinite HTTP request will result in the unit being disconnected from the network. This is done by eg. issuing a normal GET request and filling A's into an HTTP header field, like "host:". The TCP/IP implementation on the Easycom/Safecom unit is vulnerable to flooding. Sending large burst of "normal" network packets to the unit at eg. 10 mbit will result in the unit being disconnected from the network. ---=[Workaround]=- No vendor supplied workaround known. You could put your unit behind a filtering router, and make sure the ports aren't accessible from the network (except from the managing console, of course). -=[Vendor Response]=-- This issue was brought to the vendor's attention on the 30th of November, 2000. Vendor promises to look into it, but has not yet come up with any indication on when a fix would be available. == This release was brought to you by Defcom Labs [EMAIL PROTECTED] www.defcom.com ==
Re: def-2001-05: Netscape Fasttrack Server Caching DoS
On Mon, Jan 22, 2001 at 01:30:33PM +0100, Peter Grndl wrote:
Defcom Labs Advisory def-2001-05
Oooh, how fancy! ;-)
--=[Detailed Description]=
The Fasttrack 4.1 server caches requests for non-existing URLs with
valid extensions (eg. .html). The cached ressources are not freed
again (at least not after half an hour), so a malicious user could
cause the web server to perform very sluggishly, simply by requesting
a lot of non-existing html-documents on the web server.
---=[Workaround]=-
None known.
I can't test these because iPlanet's download system is too broken,
stupid, and annoying for me to grab iWS ft 4.1 to verify, but:
Almost certainly effective workaround #1:
Disable caching per http://help.netscape.com/kb/corporate/2313-1.html
Probable workaround #2:
Most of the NES/iWS built-in functions are cache-safe. That is, using
them does not prevent the server from using its cache accelerator. Some
functions are conditionally cache-safe, e.g. the "flex-log" function is
cache safe with the default configuration, but if certain attributes of
requests are logged, then the cache cannot function.
3rd-party functions are assumed to be cache-unsafe unless they
explicitly set the rq-directive_is_cacheable flag (see
http://developer.netscape.com:80/docs/manuals/enterprise/nsapi/svrplug.htm)
so you should be able to write a quick NSAPI module like this:
NSAPI_PUBLIC int PW_null(pblock *pb, Session *sn, Request *rq)
{
/* note we do not touch rq-directive_is_cacheable */
return REQ_NOACTION;
}
and then use that in obj.conf, e.g.
# near the top of obj.conf
Init fn="load-modules" shlib="/path/to/PW_null.so" funcs="PW-null"
#
# inside your Object config
Error reason="Not Found" fn="PW-null"
# then your regular 404 handler, e.g.
Error reason="Not Found" fn="send-error" path="/path/to/errorpage.html"
This should make iWS realize that the file not found URLs are not
cacheable, without affecting other documents.
I also expect that sites using query-handler instead of send-error for
their 404 errors won't have the problem Herr Gruendl describes.
-=[Vendor Response]=--
This issue was brought to the vendor's attention on the 7th of
December, 2000. Vendor replied that the Fasttrack server is not meant
for production environments and as that, the issue will not be fixed.
Also worth noting is that there do not seem to be *any* service packs
for iWS FastTrack 4.1. Since iWS Enterprise has had at least one huge
hole (remote code execution via SSL/TLS implementation bug), I expect
that iWS FastTrack is an awfully dangerous app to make available to
others. Probably a good idea to limit iWS ft to local access with some
sort of on-host firewall or packet filter.
I assume you have not found iWS Enterprise Edition to be vulnerable?
-Peter
http://www.tux.org/~peterw/
Re: ICMP fragmentation required but DF set problems.
On Sun, Jan 21, 2001 at 04:40:53PM +0100, Pavel Kankovsky wrote: On Mon, 15 Jan 2001, antirez wrote: It's possible to slowdown (a lot) connections between two arbirary hosts (but at least one with the PMTU discovery enabled) using some spoofed TCP/IP packet. Maybe you can do more against some TCP/IP stack. ... There isn't a clear solution. PMTU discovery is used by TCP (primarily if not exclusively). Isn't it possible to 1. check TCP sequence numbers in ICMP frag. needed messages generated as a response to a TCP datagram (in the same way they should be checked on any ICMP dest. unreachable to prevent a trivial DoS), 2. disregard any other ICMP frag. needed message? You can't if you wan't break the UDP PMTU discovery API that applications can use, and to look-up UDP non-connections don't seems possible. Anyway we may use this semi-fix: When the DF bit is set the IP-ID field isn't used at all. Also only packets with the DF bit set will generate the ICMP frag needed in respose, so the trick is to sign the outgoing packets with the DF bit set and store the (only 16 bit) HMAC(srcip|dstip) in the ip-id field. The key is generated at start-up and updated every X packets and/or Y seconds. When we got back the ICMP we can check the signature since the IP header is quoted. Note that you need to check the signature against the current and the last key, so in the middle case the attack may be mounted anyway using 2^14 spoofed ICMP packets in the middle case. This isn't perfect security but it's better than nothing, if you consider that this don't break anything of standard. To reach more security you may break the TOS and the HMAC will be of 24 bits, 2^23 packets required in the middle case, but actually 2^22 since you check with a bogus key (one of the two between the last and the current). Anyway this combined with a reasonable MTU-info short expiration time will make the attack quite hard, at least compared with the one packet needed with the current implementations. Obviuosly this will load your CPU, but the hash function can be quite weakfast, since the attacker can collect just an HMAC for every phisical IP address he owns. I implemented this as a netfilter hook for linux 2.4 and it works well. I wan't release beta code, expecially when in kernel space, so I'll double check it and then send it to bugtraq. My implementation uses the MD4-based trasformation that you can find under linux/drivers/char/random.c This sounds reasonable? regards, antirez -- Salvatore Sanfilippo | [EMAIL PROTECTED] http://www.kyuzz.org/antirez | PGP: finger [EMAIL PROTECTED]
[RHSA-2001:003-07] Updated mysql packages available for Red Hat Linux 7
- Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated mysql packages available for Red Hat Linux 7 Advisory ID: RHSA-2001:003-07 Issue date:2001-01-18 Updated on:2001-01-23 Product: Red Hat Linux Keywords: mysql security buffer overflow Cross references: Obsoletes: RHBA-2000:133 RHBA-2000:067 - 1. Topic: The MySQL database that shipped with Red Hat Linux 7 and the updates for it have been reported by the MySQL authors to have security problems. 2. Relevant releases/architectures: Red Hat Linux 7.0 - alpha, i386 3. Problem description: The MySQL database that shipped with Red Hat Linux 7 and the updates for it have been reported by the MySQL authors to have security problems. These problems (buffer overflow and information protection issues) have been fixed in version 3.23.32, which also contains the earlier fixes. Note that MySQL has updated its client library since the initial version shipped with Red Hat Linux 7. A new package, mysqlclient9, must be used for running applications linked with the libmysqlclient.so.9 library. 4. Solution: Because of dependencies, the packages must be installed as a group. After downloading all RPMs needed for your particular architecture, run: rpm -Uvh mysql* Note that in rare cases, the shutdown of the old database fails after upgrade - to ensure a smooth upgrade, shut the database down before upgrading: service mysqld stop 5. Bug IDs fixed (http://bugzilla.redhat.com/bugzilla for more info): 24381 - Buffer Overflow in MySQL 3.23.31 22649 - encrypt() function not supported 24589 - mysql logrotate script returns an error, log doesn't get rotated 6. RPMs required: Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/SRPMS/mysql-3.23.32-1.7.src.rpm ftp://updates.redhat.com/7.0/SRPMS/mysqlclient9-3.23.22-3.src.rpm alpha: ftp://updates.redhat.com/7.0/alpha/mysql-3.23.32-1.7.alpha.rpm ftp://updates.redhat.com/7.0/alpha/mysql-devel-3.23.32-1.7.alpha.rpm ftp://updates.redhat.com/7.0/alpha/mysql-server-3.23.32-1.7.alpha.rpm ftp://updates.redhat.com/7.0/alpha/mysqlclient9-3.23.22-3.alpha.rpm i386: ftp://updates.redhat.com/7.0/i386/mysql-3.23.32-1.7.i386.rpm ftp://updates.redhat.com/7.0/i386/mysql-devel-3.23.32-1.7.i386.rpm ftp://updates.redhat.com/7.0/i386/mysql-server-3.23.32-1.7.i386.rpm ftp://updates.redhat.com/7.0/i386/mysqlclient9-3.23.22-3.i386.rpm 7. Verification: MD5 sum Package Name -- 1d13ef56b8898abf8841510db3c0be49 7.0/SRPMS/mysql-3.23.32-1.7.src.rpm f538d811ec522c86ab890657e859a4f4 7.0/SRPMS/mysqlclient9-3.23.22-3.src.rpm c838e7245d2ca45357e556317873fcca 7.0/alpha/mysql-3.23.32-1.7.alpha.rpm 5a5049769bd785e800fe629c7875dec8 7.0/alpha/mysql-devel-3.23.32-1.7.alpha.rpm 5cb73bca58042bb7604361c224878f08 7.0/alpha/mysql-server-3.23.32-1.7.alpha.rpm e5f65a87cb3e019456d842d565693476 7.0/alpha/mysqlclient9-3.23.22-3.alpha.rpm d8097aa8c188b386803267446286a01a 7.0/i386/mysql-3.23.32-1.7.i386.rpm 528a72c7b017458f6cad65978b93305e 7.0/i386/mysql-devel-3.23.32-1.7.i386.rpm 8ec7d8b903e1608de50f49196837e40c 7.0/i386/mysql-server-3.23.32-1.7.i386.rpm 38a96abb2b68fa9354f715da47767386 7.0/i386/mysqlclient9-3.23.22-3.i386.rpm These packages are GPG signed by Red Hat, Inc. for security. Our key is available at: http://www.redhat.com/corp/contact.html You can verify each package with the following command: rpm --checksig filename If you only wish to verify that each package has not been corrupted or tampered with, examine only the md5sum with the following command: rpm --checksig --nogpg filename 8. References: http://www.mysql.com/documentation/mysql/bychapter/manual_News.html#News-3.23.31 Copyright(c) 2000, 2001 Red Hat, Inc.
Re: BugTraq: EFS Win 2000 flaw
So to suggest that your perceived EFS flaw can be resolved by over-writing is naive. The only solution is to encrypt in memory or use some removable partition as the temp space. I agree with the use of 'percevied' in this case. Though the behavior is interesting in regard to the creation of the unencrypted .tmp file, I believe this more of a procedural issue than an implementation one. Recommended EFS procedures call for the encryption of a direcory, not file-by-file as the procedure indicated by Berglind suggests. If you copy an unencrypted file and paste it into an encrypted directory, the file and the temporary file are both encrypted. This is actually covered in the docs regarding EFS. HTH. - Attonbitus Deus [EMAIL PROTECTED]
FreeBSD Security Advisory: FreeBSD-SA-01:09.crontab
-BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-01:09 Security Advisory FreeBSD, Inc. Topic: crontab allows users to read certain files Category: core Module: crontab Announced: 2001-01-23 Credits:Kyong-won Cho [EMAIL PROTECTED] Affects:FreeBSD 3.x (all releases), 4.x (all releases prior to 4.2) FreeBSD 3.5.1-STABLE and 4.1.1-STABLE prior to the correction date. Corrected: 2000-11-11 (FreeBSD 4.1.1-STABLE) 2000-11-20 (FreeBSD 3.5.1-STABLE) FreeBSD only: No I. Background crontab(8) is a program to edit crontab(5) files for use by the cron daemon, which schedules jobs to run at specified times. II. Problem Description crontab(8) was discovered to contain a vulnerability that may allow local users to read any file on the system that conform to a valid crontab(5) file syntax. Due to crontab(5) syntax requirements, the files that may be read is limited and subject to the following restrictions: * The file is a valid crontab(5) file, or: * The file is entirely commented out; every line contains either only whitespace, or begins with a '#' character. The greatest security vulnerability is the disclosure of crontab entries owned by other users, which may contain sensitive data such as keying material (although this would often be publically disclosed anyway at the time when the crontab job executes, via process arguments and environment, etc). All released versions of FreeBSD prior to the correction date including FreeBSD 4.1.1 are vulnerable to this problem. The problem was corrected prior to the release of FreeBSD 4.2. III. Impact Malicious local users can read arbitrary local files that conform to a valid crontab file syntax. IV. Workaround One of the following: 1) Utilize crontab allow/deny files (/var/cron/allow and /var/cron/deny) to limit access to use the crontab(8) utility. 2) Remove the setuid privileges from /usr/sbin/crontab. However, this will not allow users other than root to use cron. V. Solution One of the following: Upgrade the vulnerable FreeBSD system to 3.5-STABLE or 4.1.1-STABLE after the correction date. To patch your present system: download the relavent patch from the below location and execute the following commands as root: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:09/crontab-4.x.patch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:09/crontab-4.x.patch.asc Verify the detached PGP signature using your PGP utility. # cd /usr/src/usr.sbin/cron/crontab # patch -p /path/to/patch # make depend make all install -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org iQCVAwUBOm32m1UuHi5z0oilAQGA+QQAhArbkzv/lo8QibLjyEFB3lta0IC5HSrJ hPuetiP/XViZNXntIAtm26M9QGRAhw0M1s9CU6PGD0zVJHtfh/nRoNxdU9vFLhJ6 xbJf6Wai6VTJpQK7dwXKIi6nplKlOSLhd6ZhvP1fe/6bDsbYywOxJdYGJZcyKtFA vG1n8lhzhog= =EJ7/ -END PGP SIGNATURE-
Re: ICMP fragmentation required but DF set problems.
On Mon, Jan 22, 2001 at 06:15:33PM -0500, Niels Provos wrote: IPv6 is another case though. Here you have mandatory PMTU for all protocols. In this case, and even with IPv4 if you want UDP PMTU API and so on, the only way seems to sign the outgoing packets with an HMAC and a local key. So you will be able to check if the quoted packet in the ICMP error was sent by your host. With IPv4 you can use the ip.id field since it's useless with the DF bit set, but a 16 bit protection is very weak. Another way may be to add a bogus IP option, since fully-standard TCP/IP stacks will ignore the option, that contains the HMAC, but unfortunatelly all kinds of firewalls will drop this packets. With IPv6 the clearest way seems a new next-header with the HMAC that provide the autentication. No key exchange is needed, you just sign your own packets to recognize it later. antirez -- Salvatore Sanfilippo | [EMAIL PROTECTED] http://www.kyuzz.org/antirez | PGP: finger [EMAIL PROTECTED]
[CORE SDI ADVISORY] Weakl authentication in ATT's VNC
CORE SDI
http://www.core-sdi.com
Vulnerability report for weak authentication in ATT VNC
Date Published: 2001-01-23
Advisory ID: CORE-2001011501
Bugtraq ID: 2275
CVE CAN: None currently assigned.
Title: Weak authentication in ATT VNC
Class: Design error
Remotely Exploitable: yes
Locally Exploitable: no
Release Mode: USER RELEASE
Vulnerability Description:
As stated in the VNC home page ( http://www.uk.research.att.com/vnc/ ):
"VNC stands for Virtual Network Computing. It is, in essence, a remote
display system which allows you to view a computing 'desktop'
environment not only on the machine where it is running, but from
anywhere on the Internet and from a wide variety of machine
architectures".
VNC uses a challenge/response mechanism for authenticating
clients in order to avoid the transmition of clear text passwords
over insecure channels and prevent unauthorized clients to
get access to the VNC server.
A design flaw in the client authentication mechanism permits an attacker
to obtain legit credentials from a valid client in order to gain
unauthorized access to the server.
The attack can be perfomed by an attacker eavesdropping the client/server
communications with the ability to modify the data flow. NO TCP hijacking
techniques are required.
There are other security issues related to the fact that
VNC does not provide a secure transport protocol that ensures
confidentiality for the data transmited, those are well known and
considered design decisions from the VNC development team.
This advisory does not include them, the advisory addresses a
security flaw in the design of the authentication mechanism that
makes it unsuitable to fulfill its design goal.
Vulnerable Packages/Systems:
VNC up to version 3.3.3 on all supported platforms.
Solution/Vendor Information/Workaround:
It is advisable to tunnel communications between the VNC server and
client through a cryptographycally strong end-to-end authenticated
channel.
References for doing so are provided in the VNC FAQ
(http://www.uk.research.att.com/vnc/faq.html) and specifics on how to
tunnel VNC over SSH are provided at:
http://www.uk.research.att.com/vnc/sshvnc.html
Vendor notified on: 2001-01-15
Credits:
This vulnerability was found by Emiliano Kargieman, Agustin Azubel
and Maximiliano Caceres from Core SDI, http://www.core-sdi.com
This advisory was drafted with the help of the SecurityFocus.com
Vulnerability Help Team. For more information or assistance drafting
advisories please mail [EMAIL PROTECTED]
This and other CORE SDI advisories are available at:
http://www.core-sdi.com/english/publications.html
Technical Description:
1. Man in the middle attack against client/server authentication
VNC authenticates communication between client and server using a
challenge-response mechanism.
Due to design flaws in the challenge/response mechanism it is
possible to perfom a man in the middle attack and obtain
unauthorized access to the VNC server.
The client authentication mechanism is described below:
Asumming that C (the VNC client) is trying to authenticate to
S (the VNC server), the following protocol is used:
- A DES key (k) is shared by both endpoints and used for the
challenge-response.
- 'C' connects to 'S' and both endpoints exchange software/protocol
version information
- 'S' generates a 16 byte challenge and sends it to 'C'
- 'C' encrypts the received challenge with 'k' and sends the result
('rc') to 'S'
- 'S' encrypt the challenge with 'k' and compares the result ('rs')
with the response 'rc' received from the client.
- If rc==rs access is granted to the client. Otherwise access is
denied.
A classical man-in-the-middle attack can be perfomed against the
described protocol.
Assuming that the attacker ('M') has access to the data flowing between
client and server and is able to modify such data, an attack scenario
THAT DOES NOT imply a TCP session hijacking attack is outlined:
- 'M' connects to 'S' and both endpoints exchange software/protocol
version information
- 'S' generates a 16 byte challenge ('r1') and sends it to 'M', now
'M' has a connection established with 'S' with the authentication
pending a response to the server.
- 'M' waits for a connection from a legit client 'C' to 'S'
- Upon connection from the client 'C' to the server 'S', the server
(as per the protocol design) generates a 16 byte challenge
('r2') and sends it to 'C'.
- 'M' modifies the data traveling from 'S' to 'C' and replaces
'r2' with 'r1'
- 'C' receives 'r1' and encrypts it with the shared key 'k', the
result ('r1c') is sent to the server 'S'
- 'M' captures the response 'r1c' sent to the server 'S' and uses
it in its own pending connection.
- 'S' receives 2 equal responses (r1c), one from 'C'
Security Update: CSSA-2001-005.0 password sniffing in kdesu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 __ Caldera Systems, Inc. Security Advisory Subject:password sniffing in kdesu Advisory number:CSSA-2001-005.0 Issue date: 2001 January, 23 Cross reference: __ 1. Problem Description KDE2 comes with a program called kdesu that is used to run certain administration commands under the account of the super user (for instance, every time the KDE control center asks you for the root password, you actually talk to kdesu). There is a bug in kdesu that allows any user on the system to steal the passwords you enter at the kdesu prompt. 2. Vulnerable Versions System Package --- OpenLinux eDesktop 2.4 All packages previous to kdebase2-2.0-6 and kdelibs2-2.0-6 Note that you are not vulnerable if you didn't install the KDE2 update. 3. Solution Workaround: There is no real workaround for this bug, and the following is _not_ a permanent solution to the problem; this is merely a temporary solution until you have installed the update. As the super user, create directories in /tmp that have the same name as the socket used by kdesu: mkdir /tmp/kdesud_UID_0 where UID ranges over all user IDs of users on your system. Note that the trailing 0 is the display number, so if you run several X servers on your machine, you need to repeat the process for display 1, 2, etc. In order to protect just yourself, the following will do the trick: mkdir /tmp/kdesud_`id -u`_0 The proper solution is to upgrade to the fixed packages. 4. OpenLinux eDesktop 2.4 5.1 Location of Fixed Packages The upgrade packages can be found on Caldera's FTP site at: ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/RPMS/ The corresponding source code package can be found at: ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/SRPMS 5.2 Verification 23a677755332e24db259ebce9a754e14 SRPMS/kdebase2-2.0-6.src.rpm 083b8ddaf4f67d2d0b4146245034229b RPMS/kdebase2-2.0-6.i386.rpm b759a751da20a2d6c6c296da94e1656e RPMS/kdebase2-opengl-2.0-6.i386.rpm 7970d51bc04e4e23e03b01f001f56780 SRPMS/kdelibs2-2.0-6.src.rpm 20aa5f2327d8978700c22c8afce9df34 RPMS/kdelibs2-2.0-6.i386.rpm cfd8744b1950a9c5f5cf4ecd7adc0f3b RPMS/kdelibs2-devel-2.0-6.i386.rpm c922e03e8f1024a134d2542e61afca22 RPMS/kdelibs2-devel-static-2.0-6.i386.rpm d394c163bda790719881fc0defc3dca9 RPMS/kdelibs2-doc-2.0-6.i386.rpm 5.3 Installing Fixed Packages Upgrade the affected packages with the following commands: rpm -Fhv kde*2.0-6.i386.rpm 5. References This and other Caldera security resources are located at: http://www.calderasystems.com/support/security/index.html This security fix closes Caldera's internal Problem Report 8718. 6. Disclaimer Caldera Systems, Inc. is not responsible for the misuse of any of the information we provide on this website and/or through our security advisories. Our advisories are a service to our customers intended to promote secure installation and use of Caldera OpenLinux. 7. Acknowledgements Caldera Systems, Inc. wishes to thank Sebastian Krahmer (SuSE) and Waldo Bastian (KDE) for their assistance. __ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6bWEY18sy83A/qfwRAt0AAKC1eQpXRqVC2d4crHFEXaYuO08EDACfek/L XOoqPc1KETiu0+vLLy5XelU= =UqjX -END PGP SIGNATURE-
FreeBSD Ports Security Advisory: FreeBSD-SA-01:07.xfree86
-BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-01:07 Security Advisory FreeBSD, Inc. Topic: Multiple XFree86 3.3.6 vulnerabilities Category: ports Module: XFree86-3.3.6, XFree86-aoutlibs Announced: 2001-01-23 Credits:Chris Evans [EMAIL PROTECTED] Michal Zalewski [EMAIL PROTECTED] Affects:Ports collection prior to the correction date. Corrected: 2000-10-24 (XFree86-3.3.6) Vendor status: Fixed in XFree86 4.0.1, no patches released by vendor. FreeBSD only: NO I. Background XFree86 is a popular X server. It exists in three versions in the FreeBSD ports collection: 3.3.6 and 4.0.2, as well as a.out libraries based on XFree86 3.3.3. II. Problem Description The XFree86-3.3.6 port, versions prior to 3.3.6_1, has multiple vulnerabilities that may allow local or remote users to cause a denial of service attack against a vulnerable X server. Additionally, local users may be able to obtain elevated privileges under certain circumstances. X server DoS: Remote users can, by sending a malformed packet to port 6000 TCP, cause the victim's X server to freeze for several minutes. During the freeze, the mouse does not move and the screen does not update in any way. In addition, the keyboard is unresponsive, including console-switch and kill-server key combinations. Non-X processes, such as remote command-line logins and non-X applications, are unaffected by the freeze. Xlib holes: Due to various coding flaws in libX11, privileged (setuid/setgid) programs linked against libX11 may allow local users to obtain elevated privileges. libICE DoS: Due to inadequate bounds checking in libICE, a denial of service exists with any application using libICE to listen on a network port for network services. The XFree86-aoutlibs port contains the XFree86 libraries from the 3.3.3 release of XFree86, in a.out format suitable for use with applications in the legacy a.out binaryformat, most notably being the FreeBSD native version of Netscape. It is unknown whether Netscape is vulnerable to the problems described in this advisory, but it believed that the only potential vulnerability is the libICE denial-of-service condition described above. The XFree86 and XFree86-aoutlibs ports are not installed by default (although XFree86 is available as an installation option in the FreeBSD installer), nor are they "part of FreeBSD" as such: they are part of the FreeBSD ports collection, which contains almost 4500 third-party applications in a ready-to-install format. The ports collections shipped with FreeBSD 3.5.1 and 4.1.1 contain these problem since they were discovered after the releases, but the XFree86 problem was corrected prior to the release of FreeBSD 4.2. At the time of advisory release, the XFree86-aoutlibs port has not been corrected. FreeBSD makes no claim about the security of these third-party applications, although an effort is underway to provide a security audit of the most security-critical ports. III. Impact Local or remote users may cause a denial of service attack against an X server or certain X applications. Local users may obtain elevated privileges with certain X applications. If you have not chosen to install the XFree86 3.3.6 port/package or the XFree86-aoutlibs port/package, or you are running XFree86 4.0.1 or later, then your system is not vulnerable to this problem. IV. Workaround Deinstall the XFree86-3.3.6 and XFree86-aoutlibs ports/packages, if you you have installed them. Note that any statically linked binaries which make use of the vulnerable XFree86 routines may still be vulnerable to the problems after deinstallation of the port/package. However due to the difficulty of developing a reliable scanning utility for such binaries no such utility is provided. V. Solution One of the following: 1) Upgrade your entire ports collection and rebuild the XFree86-3.3.6 port. 2) Deinstall the old package and install an XFree86-4.0.2 package obtained from: [i386] ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/x11/XFree86-4.0.2_5.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/x11/XFree86-4.0.2_5.tgz ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/x11/XFree86-4.0.2_5.tgz [alpha] Packages are not automatically generated for the alpha architecture at this time due to lack of build resources. NOTE: XFree86-3.3.6 packages are no longer made available, only the newer XFree86-4.0.2 packages. Note also that the XFree86-aoutlibs port has not yet been fixed: there is currently no solution to the problem other than removing the port/package and recompiling any dependent software to use ELF libraries, or switching to an ELF-based version of the software, if available (e.g. the
win32/memory locking (Re: Reply to EFS note on Bugtraq)
On Mon, Jan 22, 2001 at 05:28:50PM -0800, Ryan Russell wrote: Due to some mail trouble, I'm manually forwarding this note. From: Microsoft Security Response Center Subject:Re: BugTraq: EFS Win 2000 flaw "... it is recommended that it is always better to start by creating an empty encrypted folder and creating files directly in that folder. Doing so, ensures that plaintext bits of that file never get saved anywhere on the disk. It also has a better performance as EFS does not need to create a backup and then delete the backup, etc." Bits _never_ get written to the disk? Guaranteed never to use swap space? The GnuPG FAQ (http://www.gnupg.org/faq.html#q6.1) suggests that it is not possible to make a Windows program insist on physical RAM the way a program can in Open Systems. Does EFS really use only physical RAM? If so, is there some win32 API that can be used by other application designers who want to guarantee that certain blocks of allocated memory are *never* swapped out to disk? The most likely candidate I've come across is VirtualLock() which, unfortunately, "does not mean that the page will not be paged to disk" (http://msdn.microsoft.com/library/techart/msdn_virtmm.htm). Thanks, -Peter
[SECURITY] [DSA 018-1] New version of tinyproxy released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-018-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 23, 2001 - Package: tinyproxy Vulnerability : remote nobody exploit Debian-specific: no PkC have found a heap overflow in tinyproxy that could be remotely exploited. An attacker could gain a shell (user nobody) remotely. We recommend you upgrade your tinyproxy package immediately. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Potato was released for the alpha, arm, i386, m68k, powerpc and sparc architectures. Source archives: http://security.debian.org/dists/stable/updates/main/source/tinyproxy_1.3.1-2.diff.gz MD5 checksum: 747119973db206dfa681357262b92e05 http://security.debian.org/dists/stable/updates/main/source/tinyproxy_1.3.1-2.dsc MD5 checksum: b7566742b8d8f4ff165463b6ab7d9855 http://security.debian.org/dists/stable/updates/main/source/tinyproxy_1.3.1.orig.tar.gz MD5 checksum: b81229f1cb0212cb12e3bfdbaccdb820 Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/tinyproxy_1.3.1-2_i386.deb MD5 checksum: e542b2d9f936912d2b5d39eb2adbf39d Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/tinyproxy_1.3.1-2_m68k.deb MD5 checksum: e73a5a6cd23ef8a9d6e35ada4b809515 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/tinyproxy_1.3.1-2_sparc.deb MD5 checksum: 98352a16b4dae2724f89e689c4d25d0e Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/tinyproxy_1.3.1-2_alpha.deb MD5 checksum: 1c535ecf48a66d30a19246d45de8c40a PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/tinyproxy_1.3.1-2_powerpc.deb MD5 checksum: 9815f334c4954841a7025be8bde96776 ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/tinyproxy_1.3.1-2_arm.deb MD5 checksum: 2bb2d2793731b196aaebad9c396b3af0 These files will be moved into ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. For not yet released architectures please refer to the appropriate directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ . - 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 pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6bfo+W5ql+IAeqTIRAgnEAJ445ztA5GrwpGbQCWB7ZkS6H430OACghIvN S8NLr/T7dxpcgIP6yZAgNJk= =bIEj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[SECURITY] [DSA-014-1] New version of splitvt released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-014-1 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 23, 2001 - Package: splitvt Vulnerability : buffer overflow and format string attack Debian-specific: no It was reported recently that splitvt is vulnerable to numerous buffer overflow attack and a format string attack. An attacker was able to gain access to the tty group. We recommend you upgrade your splitvt package immediately. wget url will fetch the file for you dpkg -i file.deb will install the referenced file. You may use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Potato was released for the alpha, arm, i386, m68k, powerpc and sparc architectures. Source archives: http://security.debian.org/dists/stable/updates/main/source/splitvt_1.6.3-7.1.diff.gz MD5 checksum: 158e4c37b56d09e4fb7e6d4a1eda6551 http://security.debian.org/dists/stable/updates/main/source/splitvt_1.6.3-7.1.dsc MD5 checksum: c7924da369529b09acf6a7234ec07c08 http://security.debian.org/dists/stable/updates/main/source/splitvt_1.6.3.orig.tar.gz MD5 checksum: e95e166145ec51d2a9d80aa6472f9f98 http://security.debian.org/dists/stable/updates/main/source/splitvt_1.6.5-0potato1.diff.gz MD5 checksum: 475d1066c013102625c79757b3615d9b http://security.debian.org/dists/stable/updates/main/source/splitvt_1.6.5-0potato1.dsc MD5 checksum: dcfd3f56c5f7a3686e35a2de47614944 http://security.debian.org/dists/stable/updates/main/source/splitvt_1.6.5.orig.tar.gz MD5 checksum: f93974daa4f39945b3d5b9cc39bb1b0f Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/splitvt_1.6.3-7.1_i386.deb MD5 checksum: d814d49f46f8108590554abc8ed79737 http://security.debian.org/dists/stable/updates/main/binary-i386/splitvt_1.6.5-0potato1_i386.deb MD5 checksum: ccb41228b11505bb25dc2f09830b3964 Motorola 680x0 architecture: http://security.debian.org/dists/stable/updates/main/binary-m68k/splitvt_1.6.5-0potato1_m68k.deb MD5 checksum: fae77f348ae28c89de0e51965cbafd35 Sun Sparc architecture: http://security.debian.org/dists/stable/updates/main/binary-sparc/splitvt_1.6.3-7.1_sparc.deb MD5 checksum: 4197c4e30fe5e9f48187ba8df3526c7b http://security.debian.org/dists/stable/updates/main/binary-sparc/splitvt_1.6.5-0potato1_sparc.deb MD5 checksum: 7bfd098f4a8f884a63805ae13c1e9cea Alpha architecture: http://security.debian.org/dists/stable/updates/main/binary-alpha/splitvt_1.6.5-0potato1_alpha.deb MD5 checksum: e960372181b65e167c41f36707ef48cf PowerPC architecture: http://security.debian.org/dists/stable/updates/main/binary-powerpc/splitvt_1.6.5-0potato1_powerpc.deb MD5 checksum: d0d3b36c20b2999c7c7610a48866167e ARM architecture: http://security.debian.org/dists/stable/updates/main/binary-arm/splitvt_1.6.5-0potato1_arm.deb MD5 checksum: 1d697bed936476ae88fd478aba112be8 These files will be moved into ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. For not yet released architectures please refer to the appropriate directory ftp://ftp.debian.org/debian/dists/sid/binary-$arch/ . - 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 pkg' and http://packages.debian.org/pkg -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6bNCrW5ql+IAeqTIRAqfqAJwMgM4s5GXEnSr98z630bk6YNhfDACfYjzj GyZpBtaYKh+Zmku9aeYrqAs= =g5Wy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FreeBSD Security Advisory: FreeBSD-SA-01:08.ipfw
-BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-01:08 Security Advisory FreeBSD, Inc. Topic: ipfw/ip6fw allows bypassing of 'established' keyword Category: core Module: kernel Announced: 2001-01-23 Credits:Aragon Gouveia [EMAIL PROTECTED] Affects:FreeBSD 3.x (all releases), FreeBSD 4.x (all releases), FreeBSD 3.5-STABLE and 4.2-STABLE prior to the correction date. Corrected: 2001-01-09 (FreeBSD 4.2-STABLE) 2001-01-12 (FreeBSD 3.5-STABLE) FreeBSD only: Yes I. Background ipfw is a system facility which allows IP packet filtering, redirecting, and traffic accounting. ip6fw is the corresponding utility for IPv6 networks, included in FreeBSD 4.0 and above. It is based on an old version of ipfw and does not contain as many features. II. Problem Description Due to overloading of the TCP reserved flags field, ipfw and ip6fw incorrectly treat all TCP packets with the ECE flag set as being part of an established TCP connection, which will therefore match a corresponding ipfw rule containing the 'established' qualifier, even if the packet is not part of an established connection. The ECE flag is not believed to be in common use on the Internet at present, but is part of an experimental extension to TCP for congestion notification. At least one other major operating system will emit TCP packets with the ECE flag set under certain operating conditions. Only systems which have enabled ipfw or ip6fw and use a ruleset containing TCP rules which make use of the 'established' qualifier, such as "allow tcp from any to any established", are vulnerable. The exact impact of the vulnerability on such systems is undetermined and depends on the exact ruleset in use. All released versions of FreeBSD prior to the correction date including FreeBSD 3.5.1 and FreeBSD 4.2 are vulnerable, but it was corrected prior to the (future) release of FreeBSD 4.3. III. Impact Remote attackers who construct TCP packets with the ECE flag set may bypass certain ipfw rules, allowing them to potentially circumvent the firewall. IV. Workaround Because the vulnerability only affects 'established' rules and ECE- flagged TCP packets, this vulnerability can be removed by adjusting the system's rulesets. In general, it is possible to express most 'established' rules in terms of a general TCP rule (with no TCP flag qualifications) and a 'setup' rule, but may require some restructuring and renumbering of the ruleset. V. Solution One of the following: 1) Upgrade the vulnerable FreeBSD system to FreeBSD 3.5-STABLE, or or 4.2-STABLE after the correction date. 2) Patch your present system by downloading the relevant patch from the below location: [FreeBSD 4.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-4.x.patch.asc [FreeBSD 3.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:08/ipfw-3.x.patch.asc Verify the detached PGP signature using your PGP utility. Execute the following commands as root: # cd /usr/src # patch -p /path/to/patch # cp /usr/src/sys/netinet/tcp.h /usr/src/sys/netinet/ip_fw.h /usr/include/netinet/ # cd /usr/src/sbin/ipfw # make depend make all install # cd /usr/src/sys/modules/ipfw # make depend make all install For 4.x systems, perform the following additional steps: # cp /usr/src/sys/netinet6/ip6_fw.h /usr/include/netinet6/ # cd /usr/src/sbin/ip6fw # make depend make all install # cd /usr/src/sys/modules/ip6fw # make depend make all install NOTE: The ip6fw patches have not yet been tested but are believed to be correct. The ip6fw software is not currently maintained and may be removed in a future release. If the system is using the ipfw or ip6fw kernel modules (see kldstat(8)), the module may be unloaded and the corrected module loaded into the kernel using kldload(8)/kldunload(8). This will require that the firewall rules be reloaded, usually be executing the /etc/rc.firewall script. Because the loading of the ipfw or ip6fw module will result in the system denying all packets by default, this should only be attempted when accessing the system via console or by careful use of a command such as: # kldload ipfw sh /etc/rc.firewall which performs both operations sequentially. Otherwise, if the system has ipfw or ip6fw compiled into the kernel, the kernel will also have to be recompiled and installed, and the system will have to be rebooted for the changes to take effect. -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For info see http://www.gnupg.org
Re: BugTraq: EFS Win 2000 flaw
Dan Kaminsky [EMAIL PROTECTED] writes: That means no decryption keys ever get written, no passwords get saved, and most importantly, *no plaintext data gets stored, not even "temporarily"*. Interestingly, when a system hibernates everything in memory goes to disk (into the hiber file or partition)-- and this includes the sensitive data that the LSA holds that is not normally swapped out: keypairs, kerberos tickets and encrypted files.
Make The Netopia R9100 Router To Crash
This post will be short because it does not need a lot of explanation. This is in a really specific case. If you have the password of the router and if you are logged to it you will not be able to delete all the traces. The router logs the connection and the disconnection of telnet sessions. If you want to delete the connection from the logs you just have to delete them. But if you want to delete the disconnection log you can't. The only way to do that is to make it crash. Just use the telnet program which is inside the router. Try to make a connection from the IP of the router to the IP of the router. It will crash it, as a consequence, you will NOT be logged ! In the log you only see things like that : 01/24/01 01:01:15 --BOOT: Warm start v4.6 01/24/01 01:01:10 * EXCEPTION: A6: 12F6890, A7: 12F67DC 01/24/01 01:01:10 * EXCEPTION: A4: 0, A5: 124B474 01/24/01 01:01:10 * EXCEPTION: A2: 125F9AC, A3: 0 01/24/01 01:01:10 * EXCEPTION: A0: 125F9D8, A1: 0 01/24/01 01:01:10 * EXCEPTION: D6: 0, D7: C1FB0028 01/24/01 01:01:10 * EXCEPTION: D4: 0, D5: 0 01/24/01 01:01:10 * EXCEPTION: D2: 0, D3: 0 01/24/01 01:01:10 * EXCEPTION: D0: 0, D1: 6 01/24/01 01:01:10 * EXCEPTION: BERR SF SP+$10: 10845AE, SP+$14: E0045 01/24/01 01:01:10 * EXCEPTION: BERR SF SP+$08: 83A, SP+$0C: F9AC 01/24/01 01:01:10 * EXCEPTION: PC: 10845AE, SR: 2004, F/V: C008
