Re: win32/memory locking (Re: Reply to EFS note on Bugtraq)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 As described on the MSDN site: "The AllocateUserPhysicalPages function is used to allocate physical memory. Memory allocated by this function must be physically present in the system. Once allocated, it is locked down and unavailable to the rest of the virtual memory management system of Windows 2000." _http://msdn.microsoft.com/library/psdk/winbase/memman_0u5v.htm_ The UserPhysicalPages class of functions appear to be directly related to kernel calls, so I'd take a guess and say it's probably what you're looking for. - James Perry -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (GNU/Linux) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iD8DBQE6bp0ds6J9OMPOxE8RAki4AKCiTWweQkkvcRWBqUyXJDQEFu8yngCfYNP8 f/adsAYRzRYstL63pJZSZbo= =g2j5 -END PGP SIGNATURE-
iPlanet FastTrack/Enterprise 4.1 DoS clarifications
Regarding Peter Guendl's discovery of DoS attacks against iWS 4.1: 1) Peter G. reports that disabling the cache with cache-init is not an effective workaround for the FastTrack problem. 2) I wrote that iWS 4.1 has "at least one huge hole (remote code execution via SSL/TLS implementation bug)". Another reader has pointed out that the SSL/TLS problem was announced as a Denial of Service vulnerability. 3) The note about Service Pack levels for iPlanet Enterprise 4.1 in Peter Gruendl's "Netscape Enterprise Server Dot-Dot DoS" was somewhat confusing. The iPlanet URL he refers to correctly states that the latest supported iPlanet Web servers[0] are 4.0sp6 and 4.1sp5. 4.1sp6 has not been released or officially announced by iPlanet. Thanks, -Peter [0] All Netscape-branded Web server products, including Netscape Enterprise 3.6, have officially passed their end-of-life dates and are no longer supported.
Re: Make The Netopia R9100 Router To Crash
Well, had you bothered to contact Netopia first, (what!, you didn't! shame on you!), you would have found that the problem has been resolved for some time now. The version of firmware against which you are reporting this problem (4.6) is close to a year old. The current version of firmware is 4.8.2, or two feature releases and a number of bug fixes removed. Please upgrade to 4.8.2. In the future, you should report security problems to [EMAIL PROTECTED] or call Netopia Tech Support and have the problem logged so that it can either be fixed, or as in this case, you can be directed to upgrade your firmware. rwt ps. Whose router do you have passwords to anyhow:^? And why are you trying to delete the logs:^? --- Robert Tashjian [EMAIL PROTECTED] - Original Message - From: "Julien Henry" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 23, 2001 1:59 PM Subject: 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
Re: BugTraq: EFS Win 2000 flaw
This entire thread and problem is basic computer crypto. If you want something to be safe, you never store it plaintext, period. Granted, EFS doesn't have loud red warnings if you encrypt a file that was previously plaintext, but at the end of the day, this is not an EFS flaw---pure user error. Perhaps a nice "safety feature" in EFS would be offering to do a "secure wipe" or what have you on the plaintext file area(s) when you do a file copy to an encrypted folder or change the encryption tag on a regular file... but at the end of the day, if you want it secure, it should be created and maintainted in a secure environment (read: in the encrypted directory). PGP volumes and every other form of volume/full drive encryption has the identical problem. None of them warn you at all. In fact, EFS is a little *nicer* in the sense that if you drag an encrypted file OUT of an encrypted folder, it will keep it encrypted. Saves you the reverse mistake of decrypting and storing a previously encrypted file. Of course that's the advantage of using file tagging instead of PGP "volume" style encryption. Cheers, Ben -- Benjamin P. Grubin[EMAIL PROTECTED] Guardent, Inc. http://www.guardent.com PGP Key: D33D 22C2 6552 0F6B 44E4 5254 0172 0E10 "The world isn't run by weapons anymore, or energy, or money. It's run by little ones and zeros, little bits of data.. it's all just electrons." -Original Message- From: Rickard Berglind [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 6:30 AM 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 attacker to gain control over secret information. Here is a description how to test this : Use any version of Windows 2000. Install the Support Tools from the Win2000 CD. For demonstrating purposes - create a new partition with the size of 7 MB. Choose to format with NTFS. Create a new small file ( easier to find ) with Notepad and put some text in it. Save this file in the root of the new partition. Do not encrypt it yet. Let us look at the file through DiskProbe before encryption- start Diskprobe from Support Tools on the Start Menu. A. Choose the "Drives"-menu and "Physical Drive" Double click on "physical drive 0" ( or other drive you are using ) Click "Set active" and then "OK" B. Choose "Drives" again and this time "Logical Volume" Double click the drive letter for your new partition and then "Set active" and "OK" C. Choose the "Sectors"-menu and "Read". For starting number type 80 and for the number - 35 perpaps. Maximize the window and click the arrow for "Next sector". At sector 86 you should see the name and contents of your file ( assuming you made a new partition ) The file is obiously in plain text and easy to read for anyone with physical access to this disk, regardless of permissions in the ACL, which is ignored when using this kind of utiliy. Better encrypt this file .. ! Now close the DiskProbe utility and open Explorer and locate your new file. Choose Properties - Advanced - Encrypted - OK. The file is now
Re: win32/memory locking (Re: Reply to EFS note on Bugtraq)
From: Peter W [mailto:[EMAIL PROTECTED]] 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). This is certainly possible as EFS is a kernel mode device driver and not a Win32 application. Non pageable memory can be easily allocated from the non-paged pool by a device driver (and is one of the fundamental concepts in writing a Win2000 driver). The EFS driver communicates with the local security authority (lsass) to allow the use of CryptoAPI for encryption of the data, but as lsass is a Native applciation (not Win32) then it may have access to other (undocumented) functions, or simply pass a pointer to the non-paged memory it has allocated for the encryption buffers. Note that the PGP implementation uses a device driver (PGPmemlock.sys) to lock pages into memory and prevent them from being swapped out. I am unsure as to the motives of the GPG team if they have not implemented a similar feature, but smells like FUD to me. John Wiltshire
[SECURITY] [DSA-016-2] Correction: New version of wu-ftpd released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-016-2 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 23, 2001 - Package: wu-ftpd Vulnerability : temp file creation and format string Debian-specific: no Security people at WireX have noticed a temp file creation bug and the WU-FTPD development team has found a possible format string bug in wu-ftpd. Both could be remotely exploited, though no such exploit exists currently. This additional advisory only announces a recompile of the package for the Intel ia32 architecture. The upload from yesterday was lacking PAM support. This only required a recompile and contains no other fixes. For upgrading please use wget url will fetch the file for you dpkg -i file.deb will install the referenced file. Or use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/wu-ftpd_2.6.0-5.2_i386.deb MD5 checksum: 5cdd2172e1b2459f1115cf034c91fe40 These files will be moved into ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. - 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 iD8DBQE6bgv4W5ql+IAeqTIRAvECAKCtIyPmTnk9jneoaxAlHSV22CQL5gCcCFaI uoq9CpnzjZKsn5lQ9EAN1FU= =Tx2U -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq: EFS Win 2000 flaw
The URL given by Dan Kaminsky in a previous message for the Peter Gutmann paper "Secure Deletion of Data from Magnetic and Solid-State Memory" seems to be not working. A working URL is: http://www.cs.auckland.ac.nz/~pgut001/secure_del.html Ben Greenbaum Director of Site Content SecurityFocus http://www.securityfocus.com
[SECURITY] [DSA-016-3] Correction: New version of wu-ftpd released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Debian Security Advisory DSA-016-3 [EMAIL PROTECTED] http://www.debian.org/security/ Martin Schulze January 24, 2001 - Package: wu-ftpd Vulnerability : temp file creation and format string Debian-specific: no Security people at WireX have noticed a temp file creation bug and the WU-FTPD development team has found a possible format string bug in wu-ftpd. Both could be remotely exploited, though no such exploit exists currently. This additional advisory only announces a recompile of the package for the Intel ia32 architecture. The upload from yesterday was lacking PAM support. This only required a recompile and contains no other fixes. (Sorry, but when I make a mistake, I have to make it real, this time it's the correct file). For upgrading please use wget url will fetch the file for you dpkg -i file.deb will install the referenced file. Or use an automated update by adding the resources from the footer to the proper configuration. Debian GNU/Linux 2.2 alias potato - Intel ia32 architecture: http://security.debian.org/dists/stable/updates/main/binary-i386/wu-ftpd_2.6.0-5.2.1_i386.deb MD5 checksum: e0521153d6c9c23082edb29cc8d03fd3 These files will be moved into ftp://ftp.debian.org/debian/dists/stable/*/binary-$arch/ soon. - 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 iD8DBQE6bn2HW5ql+IAeqTIRAlxRAJ9JIj0KvmI1mnY19lnUICUjzce8vwCfQMvS rwEZYHHmhMiSVU1+4BdCwKA= =JJUl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BugTraq: EFS Win 2000 flaw
I've got a couple of question on this issue.. The concern is that a temp file of the original plaintext may be left around for an attack to "undelete". It's understandable why this might be neccessary for a rollback in case of machine failure at just the wrong time. (Though one could argue that that's what backups are for.. since you could lose the file to a blackout either before or after the encrypt operation, I'm not so sure why it's such a big deal if you lose it during.) Where does the encrypted file go when it's done? Does the OS make sure it goes back on the same sectors where the original unencrypted file was? If not, then then original plaintext file is lying around with the delete flag set, and the temp file is a bit of a moot point. If the crypted bits are carefully written over the plaintext bits, then yes, the temp file being left in plaintext on disk seems like a silly mistake. How about this set of steps to ensure careful overwriting of plaintext: -Leave plaintext file where it is for the moment -Create a temp file which consists of the crypted version of the plaintext -Swap file names (file.txt and file.txt.tmp) The file with the .tmp extension is now the plaintext version. -Copy crypted bits over the plaintext bits (i.e. copy file.txt file.txt.tmp) -Mark file.txt.tmp as deleted There are points during this process where you can halt the machine, and there will be a plaintext version left on disk. Since you started with a plaintext on disk to begin with, it's not possible to create a set of steps that might be interrupted at the wrong time and not leave plaintext on the disk. At least, not if you want to maintain the rollback feature. None of this takes into account the possibility that one can get previous generations of writes via some mechanism. Heck, it doesn't even take into account that the drive might decide all of a sudden that it doesn't like that sector anymore, and remap it under your OS' nose, without it knowing a thing about it... leaving the original sector physically on the disk, at the top layer of writes, but totally unavailable to normal software. Which boils down to me agreeing with Dan's statement... the only way to make sure your plaintext doesn't come back to haunt you is to never write it to disk. For EFS, I believe this would require you taking a virgin drive and creating nothing but EFS partitions that cover the entire drive, and THEN do your work. Ryan
Re: BugTraq: EFS Win 2000 flaw
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. Ahem. Been seeing alot of this. RTFM is actually not the correct response to a security hole--among other things, "the docs" is insufficient information for me to determine which is the canonical and mandatory docs I'm supposed to address as The One And True Docs. If you ask me, the user interface itself is the most important documentation--it's the only thing that, if it's incorrect, is *guaranteed* to lead to the wrong thing being done. The user interface states that a file can be taken from an insecure state to a secure state by checking "encrypt file". That's it. You get a warning, and the warning states that unless the folder as a whole is encrypted, a change in the file might lead to decrypted content being saved. That's it. I think my real problem with people running to the docs is that, quite frankly, the *reason* for something to be recommended is *critical*. According to the UI itself, the reason folder-crypto is superior is because "modified files might be saved in cleartext." According to the "Step By Step Guide To EFS" (http://www.microsoft.com/technet/win2000/efsguide.asp), the reason it's recommended is "because many existing applications are not aware of encryption and can therefore render the file in clear text." Assume I've read both pieces of documentation--if I don't plan to modify the file and if I'm using non-legacy applications, I should be safe. After all, if the real recommended reason was "use of this feature will render the encryption completely irrelevant to anyone with a sector editor", why, the feature wouldn't even be in Windows, wouldn't it? MS is failing to overwrite, even once, either the original file or the .tmp file that EFS creates. That's a bug. It's not *nearly* as significant as the possibility that MS was plaintext writing *everything*, and just converting to encrypted form in the background(which is exactly what I thought it was doing), but it's an issue and they're likely to address it. Simply recommending a given pattern of behavior is irrelevant. Nobody should be faulted, not even slightly, for passing over the recommendations given that they were given without reasons that Rickard made clear. Yours Truly, Dan Kaminsky Cisco Systems, Inc. http://www.doxpara.com
Re: win32/memory locking (Re: Reply to EFS note on Bugtraq)
Quoting James Perry [EMAIL PROTECTED]: As described on the MSDN site: "The AllocateUserPhysicalPages function is used to allocate physical memory. Memory allocated by this function must be physically present in the system. Once allocated, it is locked down and unavailable to the rest of the virtual memory management system of Windows 2000." _http://msdn.microsoft.com/library/psdk/winbase/memman_0u5v.htm_ The UserPhysicalPages class of functions appear to be directly related to kernel calls, so I'd take a guess and say it's probably what you're looking for. - James Perry AllocateUserPhysicalPages() is only available on Windows 2000. VirtualAlloc() with the PAGE_NOCACHE flag is available for Windows NT 3.1+ and Windows 95+. From the MSDN Library: PAGE_NOCACHE - Allows no caching of the committed regions of pages. The hardware attributes for the physical memory should be specified as "no cache." This is not recommended for general usage. It is useful for device drivers; for example, mapping a video frame buffer with no caching. This value is a page protection modifier, and it is only valid when used with one of the page protections other than PAGE_NOACCESS. Keith Ray [EMAIL PROTECTED] http://www.nullify.org PGP - 0xAE1B3529 - 8227 60E5 BAA5 9461 CAB3 A6F2 4DFE F573 AE1B 3529
Re: win32/memory locking
On Wed, 24 Jan 2001, John Wiltshire wrote: Note that the PGP implementation uses a device driver (PGPmemlock.sys) to lock pages into memory and prevent them from being swapped out. I am unsure as to the motives of the GPG team if they have not implemented a similar feature, but smells like FUD to me. Mainly a lack of time hinders the implementation of such a driver. And frankly, I don't think it does make much sense to do so because you can attack 99.9% of all Windows boxes by other and simpler means. If a customer of mine would demand such a thing, I am going to write it of course. Werner -- Werner Koch [EMAIL PROTECTED] GNU Privacy Guard(http://www.gnupg.org) Free Software Foundation Europe (http://www.fsfeurope.org) [Please see X-* mail header for OpenPGP key info]
Re: BugTraq: EFS Win 2000 flaw
Addendum to my thoughts on the apparent EFS design flaw, which is actually less significant than originally announced. Essentially, only files that are converted FROM plaintext TO ciphertext are temped, meaning the bug only affects files that were plaintext on the disk in the first place. There's still a problem--temp files aren't overwritten, not even once--but EFS doesn't become *at all* farce of a FS I thought it was. (Of course, I didn't know this as I wrote much of what's below, so if something reads funny...that's why.) Specific kudos to Scott Culp at Microsoft, whose response to Rickard's post was well researched and nicely done. 1) As quite a few people noticed, I pasted in the wrong URL for Peter Gutmann's Secure Deletion paper. Ironic that, for all that I tend to talk about the dangers of intermittent failures(as opposed to the clear-cut loss of service that tech support is generally built to verify and address), Windows' occasional tendancy to ignore a copy request would hit me. The *correct* URL is as follows. http://www.cs.auckland.ac.nz/~pgut001/secure_del.html This is incredible reading, even now, five years after it was authored. [Yes, Ben had to make a special post with the above URL, but I'm repeating it as an exhortation to everyone: Read It!] 2) According to Russ Cooper(editor of NTBugTraq), Gutmann, as of two years ago, said that the increased disk densities weren't yet posing a problem for disk data recovery. This fits well with the presumption that, as densities go up, redundancies and error correction codes also increase their effectiveness. A moderately interesting facet of memory design is that apparently nearly every single DIMM has defects, but each chip on that DIMM has extra blocks and integrated circuitry to detect bad memory and transparently reroute into the extra storage areas. This increases yields by providing tolerance against minor imperfections, at the cost of a slightly larger die. More importantly to us, however, is the reassertion that logical reality has no required relationship with physical reality. Memory can be logically sequential and physically random. IP addresses can be logically grouped and physically diverse. Content on a hard drive can be logically erased but physically immortal, due perhaps to a freak accident that causes a block to be marked as bad and transparently duplicated elsewhere. Remove from a hard drive read head the constraints of size, mass production, writability, non-destructivity, and even the requirement to survive shipping, and it becomes very clear how simply because *one* physical apparatus (the read/write head shipped with the hard drive) cannot logically analyze a set of faded impressions in the magnetic media, that no other physical apparatus might. Interestingly enough, the variation in "physical agility" doesn't just apply to readability; the ability to create physical impressions is also something that varies absolutely unpredictably according to the flow of time, money, and criticality. Since the sanctity of physical impressions are exactly what biometric systems attempt to authenticate against, one should realize that a similar risk factor exists in biometric spoofing as exists in multi-generation data recovery--more risk, since you probably don't need a clean room and expensive sensors to spoof a $25 optical fingerprint scanner; less risk, since hard drive data recovery doesn't require aquisition of the secret(although it's likely that the last person to use that $25 fingerprint scanner will leave their prints on the scanner!) The advantage of cryptography is that, overall, the belief that there's no efficient way to factor the product of two large primes is more "secure" than the belief that there's no way to physically spoof a given set of physical properties. Done correctly, it allows us to *ignore* the possibility that our physical data routes might get compromised. No, we don't lose *all* physical security constraints, but we're able to physically isolate the value of our information from the bulk of our data. The whole idea of an EFS is to grant the theoretical attacker full physical access to a hard drive and *still* maintain security-- all the attackers receive is encrypted bulk data. The problem, of course, is where to put the decryption key. Having a plaintext decryption key next to a whole pile of encrypted data is about as smart as etching the combination to a half ton safe right next to the wheel. (Given the cash rush into crypto, that hasn't stopped anyone from deploying such systems. The system Crypto-Gram linked to at http://www.gianus.com/ comes to mind.) So this is where crypto, for all its logical manipulations, is forced to intersect with the physical world. Many systems depend on human memory to contain some secret, although there are arguments that nobody can remember more entropy than a computer can brute force through. Other systems use hardware tokens to store their
Re: iPlanet FastTrack/Enterprise 4.1 DoS clarifications
SP6 has been released by iPlanet. http://www.iplanet.com/support/iws-alert/index.html Karubin -Original Message- From: Peter W [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 24, 2001 5:35 AM To: [EMAIL PROTECTED] Subject: iPlanet FastTrack/Enterprise 4.1 DoS clarifications Regarding Peter Guendl's discovery of DoS attacks against iWS 4.1: 1) Peter G. reports that disabling the cache with cache-init is not an effective workaround for the FastTrack problem. 2) I wrote that iWS 4.1 has "at least one huge hole (remote code execution via SSL/TLS implementation bug)". Another reader has pointed out that the SSL/TLS problem was announced as a Denial of Service vulnerability. 3) The note about Service Pack levels for iPlanet Enterprise 4.1 in Peter Gruendl's "Netscape Enterprise Server Dot-Dot DoS" was somewhat confusing. The iPlanet URL he refers to correctly states that the latest supported iPlanet Web servers[0] are 4.0sp6 and 4.1sp5. 4.1sp6 has not been released or officially announced by iPlanet. Thanks, -Peter [0] All Netscape-branded Web server products, including Netscape Enterprise 3.6, have officially passed their end-of-life dates and are no longer supported.
