Re: vixie cron possible local root compromise
"Rodrigo Barbosa (aka morcego)" wrote:
[...]
First mail:
#include wtmpx.h
main () {
printf("%d\n",__UT_NAMESIZE);
}
or, if your system does not have wtmpx.h
#include wtmp.h
main () {
printf("%d\n",UT_NAMESIZE);
}
Second mail:
On my last post, I included two simple programs to check the max length of
the login name. But the includes where wrong. Should have been utmpx.h and
utmp.h (not wtmpx.h and wtmp.h).
Sorry about the mess.
The correct codes would be:
#include wtmpx.h
main () {
printf("%d\n",__UT_NAMESIZE);
}
and
#include wtmp.h
main () {
printf("%d\n",UT_NAMESIZE);
}
Am I missing something? What's the difference bettwen codes? It is the
same code, isn't it?
Sem mais,
--
Nelson Brito
"Windows NT can also be protected from nmap OS detection scans thanks
to *Nelson Brito* ..."
Trecho do livro "Hack Proofing your Network", pgina 93
Re: vixie cron possible local root compromise
On Wed, 14 Feb 2001, Robert Varga wrote: On Mon, Feb 12, 2001 at 03:46:20PM -0800, Blake R. Swopes wrote: Considering what overflows the buffer (your username), it would seem that you'd need root access to begin with in order to craft an exploit. Am I wrong? Well this could be used to gain root privileges on free shell-account servers, which don't do the proper bounds checking and the registration process is fully automated... Many large sites allow front-line staff to add users/reset passwords/create temp accounts via suid apps (often written in-house). If this overflow is exploitable then it's possible that it would let such staff gain root where they didn't have it before. Arthur -- Arthur Clune "You have none. Get over it". Scott McNealy on on-line privacy PGP Public Key - http://www.clune.org/pubkey.txt
OS snobbery... (was Re: Bad PRNGs revisted in FreSSH)
(Another fine example of OS snobbery on Bugtraq)... On Wed, 14 Feb 2001 05:02:08 GMT, [EMAIL PROTECTED] said: FreSSH distribution -- thankfully, since just about everyone in the world *does* have a /dev/random (whatever name it's called by; this code is in an OS-dependent source file that has the appropriate name for the OS in question in it) just about nobody does get stuck with this. Unless you're AIX, Irix, Solaris In fact, unless you're anything but BSD44, linux, or svr4, by judging by the fressh 0.8 source distribution - those are the only 3 operating systems that have sys_sys_XXX.c files. However, BSD44, Linux, and SVR4 are *not* "just about everybody". -- Valdis Kletnieks Operating Systems Analyst Virginia Tech PGP signature
Re: vixie cron possible local root compromise
Note that the proposed patch... strcpy(User, pw-pw_name); --- strncpy(User, pw-pw_name, MAX_UNAME - 1); does not completely patch the hole. Okay, shellcode will get cut off, but strncpy() does not '\0'-terninate the strings but I saw that the rest of the code (notably the next line strcpy(RealUser, User); ) assumes a standard '\0'-terninated string. So, the patch would be strcpy(User, pw-pw_name); --- strncpy(User, pw-pw_name, MAX_UNAME - 1); User[MAX_UNAME-1]='\0'; wwieser
Microsoft Security Bulletin MS01-010
The following is a Security Bulletin from the Microsoft Product Security Notification Service. Please do not reply to this message, as it was sent from an unattended mailbox. -BEGIN PGP SIGNED MESSAGE- - -- Title: Patch Available for "Windows Media Player Skins File Download" Vulnerability Date: February 14, 2001 Software: Windows Media Player 7 Impact: Run arbitrary code Bulletin: MS01-010 Microsoft encourages customers to review the Security Bulletin at: http://www.microsoft.com/technet/security/bulletin/MS01-010.asp. - -- Issue: == Windows Media Player 7 introduced a feature called "skins", that allows customization of the look and feel of Windows Media Player. If a Windows Media Player skin (.WMZ) file were downloaded from a malicious web site it could potentially be used to run Java code to read and browse files on a local machine. The vulnerability stems from the fact that "skins" are downloaded to a known location on a victim's computer and are stored in a .zip package. If the .zip package contained a Java class (.class) file, any Java code in this class could be executed under the local computer security zone. If a Windows Media Player skin (.WMZ) file were downloaded from a malicious web site, it could potentially cause the deployment of zipped Java code to a known location on the visiting user's machine. Since the Java code would reside in a known location on the machine, script hosted on a hostile web site or embedded in a hostile HTML mail message could potentially invoke the script in the local computer security zone to take arbitrary action on the user's machine. Mitigating Factors: - Disable the running of unsigned Java content - Be wary of visiting malicious web sites or opening e-mail from unknown sources Patch Availability: === - A patch is available to fix this vulnerability. Please read the Security Bulletin http://www.microsoft.com/technet/security/bulletin/ms01-010.asp for information on obtaining this patch. - - THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. -BEGIN PGP SIGNATURE- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOorNCo0ZSRQxA/UrAQGW2gf/WO7Jp9PXvCspTxQ+ZKgJtWALi1mnDz/z IfyrxZ6vIGdkgdRKCVPPHx+w27hzPvIU1B9Pm+UkcjQlj3QOWGTQjJhL3ANW1oFU 3pwGcJbv1LoibFB7Z99E+JRPWXi1JGupE2/06jCLBF/2KC9+kmu762tCfmuurlrk 44QUdnUyWxC3iIl8qEHvNZYK8qKLcKvyrn9bz5KFMcp4u9dX2SsneuSzi8FZbzxG H2CUYOF95ETKd0zdc6qr0ZIUuPMyDeF4Yjnwlx6xz0DAeFJwwhoIM4I9kV7CYZxi ODGRZFYc0QJlLtlPOsBAyngCSWseHQ7mJSTyKYEcmRev0IeMfGqOvw== =eeF9 -END PGP SIGNATURE- *** You have received this e-mail bulletin as a result of your registration to the Microsoft Product Security Notification Service. You may unsubscribe from this e-mail notification service at any time by sending an e-mail to [EMAIL PROTECTED] The subject line and message body are not used in processing the request, and can be anything you like. To verify the digital signature on this bulletin, please download our PGP key at http://www.microsoft.com/technet/security/notify.asp. For more information on the Microsoft Security Notification Service please visit http://www.microsoft.com/technet/security/notify.asp. For security-related information about Microsoft products, please visit the Microsoft Security Advisor web site at http://www.microsoft.com/security.
Call For Papers (CFP): New Security Paradigms Workshop (NSPW)
I'm the publicity chair for the New Security Paradigms Workshop. It's an academic-style workshop, so we're looking for innovative research papers. However, we are also very actively interested in new blood: "new" is what we're all about. So if folks from the practical security community here in Bugtraq have some radical new ideas on how to secure systems, consider submitting a paper, and help academia keep it real. Crispin Call For Papers New Security Paradigms Workshop 2001 An ACM/SIGSAC sponsored workshop 11 - 13 September 2001 Cloudcroft, New Mexico, USA http://www.nspw.org 2001 is the tenth anniversary of the New Security Paradigms Workshop (NSPW), which has provided a productive and highly interactive forum for innovative new approaches to computer security. The workshop offers a constructive environment where experienced researchers and practitioners work alongside newer participants in the field. The result is a unique opportunity to exchange ideas. NSPW 2001 will take place September 11 - 13, 2001 at the Cloudcroft Lodge, Cloudcroft, New Mexico, 20 miles from Alamogordo/White Sands. In order to preserve the small, focused nature of the workshop, participation is limited to authors of accepted papers and conference organizers. Because we expect new paradigms we accept wide-ranging topics in information security. Any paper that presents a significant shift in thinking about difficult security issues or builds on a previous shift is welcomed. NSPW is highly interactive in nature. Authors are encouraged to present ideas that might be considered risky in some other forum. All participants are charged with providing feedback in a constructive manner. The resulting brainstorming environment has proven to be an excellent medium for furthering the development of these ideas. Many authors have mentioned that they received more useful feedback and ideas than from any other conference. The proceedings, published after the workshop, have consistently benefited from the inclusion of workshop feedback. What makes a paper acceptable for NSPW? While we reject plenty of excellent papers that would do very well at other venues, our eclectic program committee particularly looks for new paradigms, innovative approaches to older problems, early thinking on new topics that are not necessarily fully polished, and controversial issues that might not make it into other conferences but deserve to have their try at shaking and breaking the mold. Conversely, a great paper that does not have a new paradigm, does not challenge the status quo, or does not critique an older paradigm will almost certainly get rejected. To participate, please submit your paper, justification, and attendance statement, preferably via e-mail, to both Program Chairs -- Brenda Timmerman [EMAIL PROTECTED] and Darrell Kienzle [EMAIL PROTECTED] -- by Friday, March 30, 2001 (hardcopy submissions must be received by Friday, March 23, 2001). Further details on the required format of submissions follow. 1 - Your Paper You should submit either a research paper, a 5 - 10 page position paper, or a discussion topic proposal. Submissions of any type must not have been published elsewhere. Discussion topic proposals should include an in-depth description of the topic to be discussed, a convincing argument that the topic will lead to a lively discussion, and any other supporting materials. Softcopy submissions should be in Postscript, PDF, Word/RTF or ASCII format. Papers may be submitted as hardcopy. To submit hardcopy, please mail 5 (five) copies to Program Co-chair Brenda Timmerman. Please allow adequate time for delivery. 2 - Justification You should describe, in one page or less, why your paper is appropriate for the New Security Paradigms Workshop. A good justification will describe the new paradigm being proposed, explain how it is a departure from existing theory or practice, and identify those aspects of the status quo it challenges or rejects. 3 - Attendance Statement You should state how many authors wish to attend the workshop. Accepted papers require the attendance of at least one author. In order to ensure that all papers receive equally strong feedback, all attendees are expected to stay for the entire duration of the workshop. The program committee will referee the papers and notify the authors of acceptance status by June 8, 2001. We expect to be able to offer a limited amount of financial aid to those who require it. More information will be provided on our web site http://www.nspw.org as it becomes available. Workshop General and Vice Chairs Steven J. Greenwald Cristina Serban Independent Consultant ATT Labs 2521 NE 135th
Re: Security hole in kicq
I tried with version 1.0.0, it is vulnerable for sure. Other versions (such as 2.0.0b1) seem to be vulerable as well, though i did not compile them to try. one little try shows that licq (http://licq.org) is vulerable too however the complete url will be visible to the user. greets, Wolter
Re: SSH1 key recovery patch
1){
2) static time_t last_kill_time = 0;
3) if (time(NULL) - last_kill_time 60 getppid() != 1)
4){
5) last_kill_time = time(NULL);
6) kill(SIGALRM, getppid());
7) }
8) fatal("Bad result from rsa_private_decrypt");
9)}
The rationale for the above fix is to regenerate the key whenever
a RSA operation failed - a symptom of an attacker trying to
execute the key recovery attack- this does not close the information
leakage in the ssh server (namely the existence of an oracle that can
be used to infer a session key) but it does make IMPOSSIBLE to
exploit it.
that much was clear. i just saw that it didn't actually work.
The patch intends to limit the key regeneration rate to
at most one regeneration per minute, in order to prevent
a DoS.
The problem here is that the code is executed in the context
of an sshd *child* process and therefore after the first
key regeneration the child process exits (in the fatal() function)
loosing all notion of the last time the key was regenerated.
This was spotted and reported to bugtraq by Andrew Brown, altho
the explaination of why it didnt work was not correct.
i think my explanation was correct (how was it not?) even though it
might perhaps have depended a little too much on people knowing the c
language a little more in depth.
i received no small number of personal emails explaining to me that my
analysis was incorrect based on my "misunderstanding" of the keyword
static. some people though i misread it as "auto" and some others
believed i thought it meant "const". i just didn't feel that quoting
chapter and verse from the c standard would benefit the list at all.
Below, is a new patch that does what it was originally intended.
The rate limit for key regeneration is now put in the alarm signal
handler and gets executed in the context of the sshd daemon
responsible for doing it.
much better.
/* This should really be done in the background. */
aside: fork, and write the new key back up a pipe after regeneration
is finished. ssh already depends on fork and pipe semantics, so this
ought to be trivial. sure, it's brutal and ugly, but then you don't
end up delaying connections because the server is busy.
--
|- "CODE WARRIOR" -|
[EMAIL PROTECTED] * "ah! i see you have the internet
[EMAIL PROTECTED] (Andrew Brown)that goes *ping*!"
[EMAIL PROTECTED] * "information is power -- share the wealth."
Re: vixie cron possible local root compromise
On Wed, Feb 14, 2001 at 11:34:02AM -0500, Valdis Kletnieks wrote: Of course, what's important isn't what wtmpx.h defines it as, but what pwd.h has to say about it. If getpwent() won't handle it, your wtmp format doesn't matter... Note also that some systems have utmpx.h not wtmpx.h If anyone can find any system that reports less then 32, it will be an exce= ption of the rule. Of course I mean current systems. libc5 systems, AIX 3.2 and o= ld systems like that will probably return 16 or even 8. AIX 4.3.3 and AIX 5.0 both limit it to 8 in utmpx.h Solaris 5.7 has a 32-char limit in wtmp, but has this in 'man useradd': Years of wrestling a big NIS+ cluster with sun's and linux systems teached me that one should _never_ ever completly trust anything thats just written the manual (pages) - its always better to check with the source (or at least the header's) - and check portability before anything else ;) Btw, the file-db routines in solaris (in solaris 2.4 through 2.6, dont know what 7 and 8 make of it) lib's do handle login names of up to 32 chars well. Its just that NIS+ is horribly broken when it comes to long login names (and passwords, btw ;). One does also run into big problems with all login-type daemons like ftp, rsh etc. Just a side note: in /usr/include/limits.h one can find this: (sol 2.6, 7 and 8) #define LOGNAME_MAX 8 /* max # of characters in a login name */ /* POSIX.1c conformant */ #define _POSIX_LOGIN_NAME_MAX 9 Thats one reason why i used to include limits.h in my programs ;) Moral of the story: Not all the world is Linux, and some vendors care more about backward and cross compatability than being the latest-and-greatest. ACK -- Valdis Kletnieks Operating Systems Analyst Virginia Tech Juergen -- Juergen P. Meieremail: [EMAIL PROTECTED]
BindView Advisory: MITM Attacks Against Novell NetWare
MITM Attacks Against Novell NetWare --- Issue Date: 15Feb2001 Contact: Simple Nomad [[EMAIL PROTECTED]] http://razor.bindview.com/publish/advisories/adv_NovellMITM.html Topic: -- Man-in-the-middle Attack can reveal password hashes and private keys in Novell NetWare Affected Systems: - Novell NetWare 5.0, 5.1. Unsure if NDS for other platforms (such as NT, Linux, or Solaris) are impacted, but since the client software allows connectivity to NetWare they probably are. Overview: - Novell has implemented RSA's public/private key technology for encryption and part of their authentication process. Due to protocol implementation problems, a man-in-the-middle attack could allow for password hash recovery, and even a user's RSA private key. Vendor Contact -- Novell was contacted January 26, 2001. They acknowledged the issues, will work to improve future products, and added to the mitigation section of this document. Impact: --- In theory, a network intruder could recover password hashes for cracking and system access, as well as RSA private keys for authentication. Details: Based upon the work originally put forth by Greg Miller [1], plus using further detailed information regarding the protocol [2], a more complete analysis of the protocols used during both login and authentication has been completed. The "login" protocol is the protocol used during initial authentication to a Novell Directory Services (NDS) tree. It is a hybrid cryptosystem where a symmetrical algorithm is used to encrypt data and a public-key algorithm is used to encrypt a session key. This session key is used to sign packets and to build a "credential". The "authentication" protocol is used with the credential to authenticate to additional resources, and is a variation of a Guillou-Quisquater zero-knowledge identification algorithm. [3] The Protocols - In the login protocol, we will assume hash function H is Novell's proprietary one-way hashing function [4], E(data,key) is encryption, and D(data,key) is decryption (encryption and decryption are done using RC2 in CBC mode). Novell has licensed RSA's public/private key technology, and uses the BSAFE SDK that RSA licenses. 1. Alice initiates the login sequence, and the server replies with a 4 byte random value RS1. 2. Alice generates random values RU1 and RU2, and creates datablock DU1 consisting of RU1 and RU2 (all of these datablocks contain checksums and usually some padding material to make everything multiples of 8). 3. Alice retrieves the server's RSA public key KS and computes DU2=E(DU1,KS). 4. Alice creates datablock DU3 from RS1. 5. Alice creates datablock DU4 from E(DU3,H(password,UID)). 6. Alice creates datablock DU5 from random numbers RU3 (which is small) and RU4 (which is large), and DU4. 7. Alice computes DU6=E(DU5,RU1). 8. Alice sends DU2 and DU6 to the server. 9. The server computes DU1=(DU2,server private key) and extracts RU1 which it uses to compute DU5=D(DU6,RU1) revealing RU3, RU4, and DU4. 10. The server decrypts DU3 from DU4, and verifies RS1. The server checks H against its own copy stored in NDS. If they match then Alice has typed in the correct password. 11. The server takes Alice's stored private RSA key KU and creates datablock DS1 by XORing KU with an equal number of bytes from RU4. 12. The server builds DS2 from RU3 and DS1, and then builds DS3 from a timestamp datablock called DS4, and the encryption of DS2 with DU4. The server sends DS3 to Alice. 13. Alice decrypts DS2 with DU4, verifies RU3, and XORs DS1 with RU4 to get KU. 14. Alice builds credential C from DS4, random number RU5, and her full account name in Unicode. A message digest M is taken of C, and this is encrypted with KU to get value S. S is used to sign packets. This does several things. It allows Alice to log in using her password without the password or the computed hash being transmitted across the wire in clear text. It allows Alice's RSA private key to be transmitted to Alice for creating a hash to sign packets without sending it in clear text. Now to the steps used during authentication to a secondary resource, after logging in: 1. Alice sends a request to the server whose resource she wishes to access, and sends a random value R. 2. The server generates value R2, and using Alice's public key computes X=E(K,(R+R2)). This is sent to Alice. 3. Alice decrypts X and extracts R2. R2 may be related to the time-to-live of S. 4. Alice encrypts random values R3, R4, and R5 with her private key to get E3, E4, and E5 (note here that a Guillou-Quisquater zero-knowledge identification algorithm would normally use 8 values instead of 3). 5. Alice creates E6=(E3+E4+E5+S). Alice then computes 16 byte X2=H(E6). She uses the first three byte pairs of X2 as exponent values EV1, EV2, and EV3 (the last 10 bytes are ignored). 6. Alice computes three test values (PKM
FreeBSD Security Advisory FreeBSD-SA-01:25.kerberosIV
-BEGIN PGP SIGNED MESSAGE- = FreeBSD-SA-01:25 Security Advisory FreeBSD, Inc. Topic: Local and remote vulnerabilities in Kerberos IV Category: core Module: libkrb, telnetd Announced: 2001-02-14 Credits:Jouko Pynnönen [EMAIL PROTECTED] Affects:FreeBSD 4.2-STABLE and 3.5-STABLE prior to the correction dates. Corrected: 2000-12-13 (FreeBSD 4.2-STABLE) 2000-12-15 (FreeBSD 3.5-STABLE) FreeBSD only: NO I. Background telnetd is the server for the telnet remote login protocol, which is available with optional support for the Kerberos authentication protocol. libkrb is the library used for Kerberised applications (including telnetd and login). FreeBSD includes the KTH Kerberos implementation, which is externally maintained, contributed software, as an optional part of the base system. II. Problem Description The advisory describes three vulnerabilities: first, an overflow in the libkrb KerberosIV authentication library, second, improper filtering of environmental variables by the KerberosIV-adapted telnet daemon, and finally, a temporary file vulnerability in the KerberosIV ticket management code. A buffer overflow exists in the libkrb Kerberos authentication library, which may be exploitable by malicious remote authentication servers. This vulnerability exists in the kdc_reply_cipher() call. An attacker may be able to overflow this buffer during an authentication exchange, allowing the attacker to execute arbitrary code with the privileges of the caller of kdc_reply_cipher(). The telnet protocol allows for UNIX environmental variables to be passed from the client to the user login session on the server. The base system telnet daemon, telnetd, goes the great lengths to limit the variables passed so as to prevent them from improperly influencing the login and authentication mechanisms. The telnet daemon used with KerberosIV relied on an incomplete list of improper environment variables to remove from the environment before executing the login program. This is a similar vulnerability to that described in Security Advisory 00:69. Two environment variables have been identified that place users of Kerberos at risk. The first allows the remote user to change the Kerberos server used for authentication requests, increasing the opportunity for an attacker to exploit the buffer overflow. The second allows the configuration directory for Kerberos to be modified, allowing an attacker with the right to modify the local file system to cause Kerberos to autheticate using an improper configuration (including Kerberos realm and server configuration, as well as srvtab). These vulnerabilities may be used to leverage root access. A race condition exists in the handling of ticket files in /tmp; this vulnerability may be exploited by a local user to gain ownership of arbitrary files in the file system. This vulnerability can be leveraged to gain root access. These vulnerabilities only exist on systems which have installed the optional Kerberos IV distribution (whether or not it is configured), which is not installed by default. III. Impact If your system has the KerberosIV distribution installed, remote and local users may be able to obtain root privileges on the local system. IV. Workaround To prevent remote root compromise via the telnet service, disable the telnet service, which is usually run out of inetd: comment out the following lines in /etc/inetd.conf, if present. telnet stream tcp nowait root/usr/libexec/telnetdtelnetd telnet stream tcp6nowait root/usr/libexec/telnetdtelnetd The local root compromise cannot be easily worked around. V. Solution One of the following: 1) Upgrade your vulnerable FreeBSD system to 4.2-STABLE or 3.5-STABLE after the respective correction dates. 2) Apply the relevant patch from below and recompile the affected files: Download the relevant patch and detached PGP signature from the following locations, and verify the signature using your PGP utility. [FreeBSD 4.2] ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:25/telnetd-krb.4.2.patch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:25/telnetd-krb.4.2.patch.asc [FreeBSD 3.5.1] ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:25/telnetd-krb.3.5.1.patch ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-01:25/telnetd-krb.3.5.1.patch.asc NOTE: This patch assumes you have already applied the patch in security advisory SA-00:69. Execute the following commands as root: # cd /usr/src # patch -p /path/to/patch # cd /usr/src/kerberosIV # make depend make all install # cd /usr/src/libexec/telnetd # make depend make all install -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.4 (FreeBSD) Comment: For
Re: Lotus Notes Stored Form Vulnerability
Isn't the ECL merely based on string matching of the signer rather than checking a certificate or an encrypted key? Wouldn't it be possible to create the 'Lotus Notes' domain and thus pose as 'Lotus Notes Template Development/Lotus Notes', which is accepted in the ECL by default, as they created most templates in use on the client? "Felix Grushevsky" [EMAIL PROTECTED] le 02/13/2001 09:06:09 AM Pour :Security Advisory/VMD/desjardins@VMD cc : Objet : Re: Lotus Notes Stored Form Vulnerability Guys, Again - setup ECL and try it again. Notes has Execution Control List protection for years. When it set, only code from trusted sources will be allowed to run on user workstation. Best Regards, Feliks Grushevskiy Security Advisory [EMAIL PROTECTED]@SECURITYFOCUS.COM on 12.02.2001 22:58:52 Please respond to [EMAIL PROTECTED] Sent by: Bugtraq List [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: Lotus Notes Stored Form Vulnerability I am not certain of the need to send the memo internally. There is a mail distribution option that allows the user to indicate that the recipient is a notes user, thus packaging the email in 'Notes Rich Text' format. I have successfully sent and accepted meeting invitations this way, as well as verified that commonly shared custom 'letterheads' would also follow, which means that at least some of the other fields (as well as the ones needed to route the email) also get packaged-in. Also, having or creating a 'dev' ID is hardly a problem. One needs only to be running one's own site to be free of creating any ID one wishes. At first hand, and especially without having crafted an exploit to test this, I would be one to be concerned about this possibility. Would love more info. Frank. Derek Reynolds [EMAIL PROTECTED] le 02/09/2001 11:31:58 PM Veuillez rpondre Derek Reynolds [EMAIL PROTECTED] Pour :[EMAIL PROTECTED] Objet : Re: Lotus Notes Stored Form Vulnerability Yeah I can confirm this works. I tested this awhile ago. Used the postopen event and utilized LotusScripts ability to access open APIs. I successfully was able to remotely reboot a users computer, remove their task bar among other things. You could litterly copy/paste the mellisa virus code into the postopen even and it would act the same way the virus did with Outlook/Exchange since the development environment is mimicked after VBA. Again, this would have to be crafted by someone with a developer ID and the memo would have to be sent internally. Not near as big a threat. -- Best regards, Derekmailto:[EMAIL PROTECTED] Friday, February 09, 2001, 11:13:29 AM, you wrote: CJ _ CJ Security Advisory:Lotus Notes Stored Form Vulnerability CJ Date: 8th February 2001 CJ Author: Chris Jones (aka dp) [EMAIL PROTECTED] CJ Versions Affected:At present only Lotus Notes v4.6 has been tested CJ _ CJ [ Exploit Introduction ] -- CJ Due to the design flaws of Lotus Notes databases, a user with sufficient knowledge can craft a Lotus Notes Email in such a way that the recipient only has to open the email or view the email CJ using the preview panes to become infected or to run the arbitrary code. CJ The problem lies in Lotus Notes ability to allow developers to create forms that do not rely on a specific template in a database (like normal emails) but instead uses its own in built templates CJ that travel within the document. Using these methods an experienced Lotus Notes developer could create an email enabled worm specifically for Lotus Notes networks. Which could do anything from CJ delete a few files to granting ACL rights to the persons mail box (so all emails could be viewed) to retrieving the users cached passwords or similar information. Another key point that allows CJ this exploit to occur is that the design of the mailbox database has by default been allowed to accept stored forms. CJ [ Exploit Generation ] - CJ To generate the email a malicious user will need to modify the default 'memo' form's design - which does require a developer's edition of Lotus Notes. The malicious user then has to modify the CJ forms' properties so the 'Store form in Document' action is checked. The malicious user then has a choice he could insert code into the forms 'PostOpen' event, which requires Lotus Script CJ programming knowledge or he can go the easy method and modify the forms 'Launch' properties which allows you to launch the first document attachment when opened which could be absolutely anything. CJ [ Quick Fix ] -- CJ There is a very quick and very easy method of disabling this feature and that is to
Re: ROADS search system show files Vulnerability with null bite bug
UkR-XblP writes: | Problem: Through this bug you can see any files, bug works | on every system were perl is installed. "%00" - means hex | symbol of the end of the line, used in C,C++ and perl. Hi folks - all of the ROADS 2.x series releases were vulnerable to this, and the same vulnerability existed in some of our other CGI programs. I've put together a patch which tries to fix the problem for people running ROADS 2.x, though it's specifically aimed at version 2.3. I've also rolled together the patches submitted since 2.3 was released and created a new 2.4 release. For more on these, see: http://www.roads.lut.ac.uk/lists/open-roads/2001/02/ I'm not aware of any O/S distribution including ROADS as standard (sensible people! :-), so this is only likely to be a problem for people putting their own installations together. Cheers, Martin
Re: AUTORUN Vul still work.
Nelson Brito wrote: Yeah, I know it's not a new BUG, but still work. I've read the BID 933, and I saw that there isn't a away to exploit this, so... Forgive me, the correct BID is 993. http://www.securityfocus.com/bid/993 Sem mais, -- Nelson Brito "Windows NT can also be protected from nmap OS detection scans thanks to *Nelson Brito* ..." Trecho do livro "Hack Proofing your Network", pgina 93
Re: Bug in Action Quake2 v1.52+vote
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 this bug is known about. unfortunately, the official AQ2 is no longer under development, so it probably won't get patched officially. (http://www.telefragged.net/action) however, many US servers are running AQ:E/TE 4.3d, which fixes the $$ skin bug, and many others (such as weapon farming). for more information, check out aqdt.fear.net (this is the version that the OGL requires servers to run for AQ matches, so its not as if its a very obscure sub-mod. :)) Consider trying to convince vulnerable server operators to upgrade to this version. below is a snippet of the AQ:E/TE changelog - - Dan Chin (or, in Action, [ST7]Lt.Hawkins ;) AQDT Modified Action Quake - AQ: Espionage ::snip:: v4.3a * Made $$ handling kindler and gentler v4.3 * Made several cvars _not_ serverinfo (to fix "info string length exceeded") * Fixed $$ skin bug ::snip:: -Original Message- From: Bugtraq List [mailto:[EMAIL PROTECTED]]On Behalf Of Jordan T. Sent: Wednesday, February 14, 2001 4:22 AM To: [EMAIL PROTECTED] Subject: [BUGTRAQ] Bug in Action Quake2 v1.52+vote Bugtraq, A friend of mine has discovered a possible bug in Action Quake2 teamplay v1.52+vote that allows any player to crash the server. he can be reached at [EMAIL PROTECTED] here are the details.. connect to the server, hit the console key " ` " and type this: set skin "$$" (with the double quotes) goto multiplayer options, player options, and select allow downloading and make sure you allow skin downloading then reconnect to the server and the following should happen: ]set skin "$$" ]connect 203.166.224.43:27910 Connecting to 203.166.224.43:27910... 203.166.224.43:27910: challenge 203.166.224.43:27910: client_connect The Crack Down Refusing to download a path with .. Refusing to download a path with .. Downloading players/$$/tris.md2 Server fatal crashed: FS_Read: 0 bytes read I have confirmed this. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQA/AwUBOosJoFQE03pSB7UuEQI+3QCgttzie5IcMIYeZuGf7B942/lgRpgAn1Jp 9zx0FnuNb+h82qJlQhE86gBe =fbuZ -END PGP SIGNATURE-
Re: Bad PRNGs revisted in FreSSH
On Wed, Feb 14, 2001, [EMAIL PROTECTED] wrote: * worst-case, it degenerates to the internal seeding of the OpenSSL PRNG, even if we fed it _nothing_ else at all. OpenSSL doesn't really suck about this. If you want to use OpenSSL's internal seeding, DO NOT use RAND_seed() with bogus data. If you at least used RAND_add() with an entropy estimate of 0, OpenSSL would still have the chance to stop you from using an essentially unseeded PRNG.
Re: vixie cron possible local root compromise
% uname -smr; man passwd
FreeBSD 4.2-RELEASE i386
RESTRICTIONS
username
Login name. May contain only lowercase characters or digits.
Maximum length is 16 characters (see setlogin(2) BUGS section).
The reasons for this limit are "Historical". Given that people
have traditionally wanted to break this limit for aesthetic
rea-
sons, it's never been of great importance to break such a basic
fundamental parameter in UNIX. You can change UT_NAMESIZE in
/usr/include/utmp.h and recompile the world; people have done
this and it works, but you will have problems with any precom-
piled programs, or source that assumes the 8-character name
limit
and NIS. The NIS protocol mandates an 8-character username.
If
you need a longer login name for e-mail addresses, you can
define
an alias in /etc/mail/aliases.
On HP-UX I couldn't find this information in passwd or useradd. I took a
peek at 'man utmp' and found this, but it's probably not the final word on
the subject:
structutmp {
char ut_user[8]; /* User login name */
char ut_id[4]; /* /etc/inittab id(usually
line#)*/
char ut_line[12] /* device name (console, lnxx)
*/
pid_t ut_pid; /* process id */
Sean Settle
"To sin by silence when we should protest makes cowards out of men" - Ella
Wheeler Wilcox
X Network Services Q NPC X
Phoenix, AZ
SMTP: [EMAIL PROTECTED]
-Original Message-
From: Valdis Kletnieks [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 14, 2001 9:34 AM
To: [EMAIL PROTECTED]
Subject: Re: vixie cron possible local root compromise
On Tue, 13 Feb 2001 22:27:14 -0200, "Rodrigo Barbosa (aka morcego)"
[EMAIL PROTECTED] said:
#include wtmpx.h
main () {
printf("%d\n",__UT_NAMESIZE);
}
Of course, what's important isn't what wtmpx.h defines it as, but what pwd.h
has to say about it. If getpwent() won't handle it, your wtmp format
doesn't
matter...
Note also that some systems have utmpx.h not wtmpx.h
If anyone can find any system that reports less then 32, it will be an
exce=
ption
of the rule. Of course I mean current systems. libc5 systems, AIX 3.2 and
o=
ld
systems like that will probably return 16 or even 8.
AIX 4.3.3 and AIX 5.0 both limit it to 8 in utmpx.h
Solaris 5.7 has a 32-char limit in wtmp, but has this in 'man useradd':
The login field (login ) is a string no more than eight
bytes consisting of characters from the set of alphabetic
characters, numeric characters, period (.), underscore
(_), and hypen (-). The first character should be alpha-
betic and the field should contain at least one lower case
alphabetic character. A warning message will be written if
these restrictions are not met. A future Solaris release may
refuse to accept login fields that do not meet these
requirements. The login field must contain at least one
character and must not contain a colon (:) or a newline
(\n).
SGI 6.5.10f has a 32-char limit in utmpx.h, but 'man 4 passwd' says this:
name User's login name -- consists of alphanumeric characters and
must not be greater than eight characters long. It is
recommended that the login name consist of a leading lower
case
letter followed by a combination of digits and lower case
letters for greatest portability across multiple versions of
the UNIX operating system. This recommendation can be safely
ignored for users local to IRIX systems. The pwck(1M)
command
checks for the greatest possible portability on names, and
complains about user names that do not cause problems on
IRIX.
I'll let somebody else check Tru64 and HP/UX, I don't have access to them
at the moment.
Moral of the story: Not all the world is Linux, and some vendors care
more about backward and cross compatability than being the
latest-and-greatest.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
Re: vixie cron possible local root compromise
gabriel rosenkoetter [EMAIL PROTECTED] writes: Perhaps mine was not the most thought-out reply, but people who use usernames longer than 8 characters should be aware that those usernames are NOT unique under POSIX, and useradd programs that allow them are at least *also* broken. So? Programs using features that are optional under POSIX (i.e. not required to be present on a POSIX-compliant system) are of course not broken. You say that on a system supporting 32 character usernames, "useradd" should refuse to add names longer than 8 characters? A warning would be ok, perhaps. Note that a decent frontend will surely check for the one problem you raise (which is not restricted to long usernames): uniqueness. So, if a user "eightchr" exists, adding another user "eightchr" should fail (otherwise I concur that the useradd in question is broken). Adding "eightchrsareenough" will automatically fail with "user exists" on systems considering only the first 8 charactars, and will magically work otherwise. No problem here. (No question that cron should do better bounds checking; my point was that that bounds checking should be added out of paranoia, not out of necessity.) A fix IS necessary for correctness, not paranoia. Systems supporting 9, 32, or 1024 characters in usernames are entirely compliant with relevant standards, and crontab has certainly no excuse on segfaulting over this. Bailing out is the least it must do. Deal with any length it should. -- Robbe signature.ng
Website executing javascript in SMS message
Affects: mtnsms.com and possibly other similar services About mtnsms: 4,336,000+ members, 211 partner networks in 85 countries and growing ... mtnsms.com notified on Feb 13 2001 Comment from mtnsms.com on Feb 15: "not sure why you sent us that? got a problem with spamming?" Problem description Any html or javascript included in a GSM SMS (short message service) message, sent or recieved, will be activated when a person enters the page with the message on it (Inbox or Outbox). Impact - spamming I haven´t tested this, but in theory it is possible for spammers with a SMS spam program to send messages, including the meta refresh code, to all of the users of mtnsms.com. The result would be that when a member enters their inbox he or she will directly be sent to the website chosen by the spammer. It will also be very difficult, specially if a high speed connection is used, to remove the spam for the user. Impact - individual/mass sabotage Instead of spamming, the sender could include malicious code in the message causing the browser to crash or the computer to freeze. One method is to include the meta refresh code, sending a member to a webpage with, for example, the "Self Referenced Frames Crash" which affects various o/s and/or the "Invalid WAVE Crash" (Bugtraq June 1999). Impact - sender generated The really annoying part when it comes to security is that the users themselves often cause more problems then outside attackers. This is the issue here as well. If a user sends a message containing code, the code will activate when the users visits the Outbox page. -- url: www.freespeech.org/screams -BEGIN PGP SIGNATURE- iQA/AwUAOj+s0Epl7KAh2d9BEQK9pwCf Qt7re02wzZxcGJPyqQyWWQAFnPMAn2yf EdhkgV7kgJXEXPomwWapRj4K=No9l -END PGP SIGNATURE-
AUTORUN Vul still work.
Yeah, I know it's not a new BUG, but still work. I've read the BID 933, and I saw that there isn't a away to exploit this, so... Step by Step: 1 - find a admin's mount point(a.k.a. home directory); 2 - place the autorun.inf and autorun2.exe on there; 3 - drop the admin's connection(use your prefered DoS tool); 4 - try to connect as user nelson and password nelson; 5 - BINDO, you are now a member of "Administrators" group(Stand Alone Servers) or "Domain Admins" gourp(PDC Servers). If you get a look in code, it's possible to make it more usefull making some teste, like findo PDC in domain or some others decision, easy and automatic. PS: It still works in some of Penetration Testes I have made, so it's possible usefull for all of you, I hope. PPS: It's not just a "Privilege Escalation", it's possible to create a new account with "Administrator/Domain Admin" privilege, obscurity. Sem mais, -- Nelson Brito "Windows NT can also be protected from nmap OS detection scans thanks to *Nelson Brito* ..." Trecho do livro "Hack Proofing your Network", pgina 93 autorun2.cpp autorun.ini
Re: vixie cron possible local root compromise
On Wed, Feb 14, 2001 at 12:21:14PM +0100, Robert Varga wrote: On Mon, Feb 12, 2001 at 03:46:20PM -0800, Blake R. Swopes wrote: Considering what overflows the buffer (your username), it would seem that you'd need root access to begin with in order to craft an exploit. Am I wrong? Well this could be used to gain root privileges on free shell-account servers, which don't do the proper bounds checking and the registration process is fully automated... On my RedHat 7.0 box, you can add a username longer than 20 characters using standard tools: # useradd Arnold.Schwarzenegger # su - Arnold.Schwarzenegger [Arnold.Schwarzenegger@thales Arnold.Schwarzenegger]$ crontab -e Segmentation fault I think this example negates many of the arguments in this thread, does not it? Mate --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Re: vixie cron possible local root compromise
I can't believe how much has been written about an issue that's apparently fixed with a few lines of code. More patches, less pedantic finger pointing. Bottom line is the app does not, cannot enforce length constraints on usernames, so it needs to do proper bounds checking. -Peter
Re: OS snobbery... (was Re: Bad PRNGs revisted in FreSSH)
Someone else stated elsewhere in this thread that NetBSD (one of the platforms used for FreSSH development, coincidentally) is an example of a current operating system without a /dev/random. That's actually false, and in point of fact, with the quick application of a Sun-provided patch you can even have a /dev/random on Solaris. You are correct about NetBSD, but not Solaris. The random device in SUNWski is part of the web server package in Solaris Server, but that package was dropped in Solaris 8 in favour of Apache. Also, it is not a "real", character device, it is a pipe. This does seem to make a difference for some applications. The only "real" random device for Solaris (2.5.1 through 8) is Andi Maier's at http://www.cosy.sbg.ac.at/~andi/. While it seems to work nicely, I am not aware that people have actually tested the quality of this PRNG.
Vulnerabilities in Pi3Web Server
- Begin Hush Signed Message from [EMAIL PROTECTED] - Vulnerabilities in Pi3Web Server Overview Pi3Web v1.0.1 is a web server available from http://www.zdnet.com. A vulnerability exists in the server's internal ISAPI handling procedures which results in a buffer overflow. The server also reveals the physical path of the web root upon encountering a 404 error. Details Here is an example URL that overflows a buffer in Pi3Web's executable: http://localhost/isapi/tstisapi.dll?[a lot of 'A's] This results in the following crash: ENHPI3 caused an invalid page fault in module unknown at :41414141. Registers: EAX=0001 CS=017f EIP=41414141 EFLGS=00010206 EBX=0123d1b0 SS=0187 ESP=041df3b0 EBP=041dfed4 ECX= DS=0187 ESI=041df3f0 FS=3e6f EDX= ES=0187 EDI= GS= Bytes at CS:EIP: Stack dump: 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 41414141 00bb0b2c 05611030 To discover the physical path of the web root: http://localhost/[any string which causes a 404 error] The server responds with: The original URL path was: /sadfasdf The mapped physical path was: C:\PI3WEB\WebRoot\sadfasdf Solution The buffer overflow can be prevented by deleting the ISAPI module named 'tstisapi.dll'. There is no quick solution for the web root disclosure. Vendor Status The author, John Roy, was contacted via [EMAIL PROTECTED] on Monday, February 5, 2001. No reply was received. - Joe Testa ( e-mail: [EMAIL PROTECTED] / AIM: LordSpankatron ) - Begin Hush Signature v1.3 - B2izikZHXZBSe741WqgWmHVTt5g5goAcqJzAz0tPWIrMzvB0fUWonV8Q6SUq4x4PTs+t Fqyz4+UGHO1T/IunO4J4uML1McFFFDLqSXJDyeZYd6ZvryQzRY+6WEeaBEVFFLI5X+yq F/nobN22dvqdFHrJ9PVBdYa88NieXkpAY1el3gHXiaGqYcWM1lMoub5WttkwNx9Irzpb CJlaASStNBTRBkSn84x5YkgDOgiANl7VafyNamn3X3uhJ5SHghXnUCvpueGKj6Yna9Dv wKHdyV3pg2r/UiFOfx7fy4BC5L8VOSsQZl420F1rBLxdwpnqqU3g8yiTsSs2HxG3arIF /xxa9llCxo+zKaGppx/6HGIhF8k2S6qfJcYlgmd5YhdQWMuH0A/XQhqxIGNxgJ6nY7mU qbAW7gyoXV0OFYQivjHzq6zaLE8Q7uGqBodkF/CkvbuXSAeENgECSew5bz2EblGV1Ymb 6VlmOeX5w964o01o2/2v+oFNItGYbD9N9LkHNSwNjwH4 - End Hush Signature v1.3 - \n\nThis message has been signed with a Hush Digital Signature. \nTo verify the signature, please go to www.hush.com/tools\n\n
Vulnerabilities in Bajie Http JServer
- Begin Hush Signed Message from [EMAIL PROTECTED] - Vulnerabilities in Bajie Http JServer Overview Bajie Http JServer v0.78 is a Java web server available from http://go.to/bajie and http://java.tucows.com. A vulnerability exists which allows a remote attacker to execute any CGI script on the file system by using relative paths (ie: '..', '...'). In addition, arbitrary shell commands can be executed if the server is UNIX-based. Details A servlet named 'UploadServlet' is installed by default which allows anyone to upload a file to a directory outside the web root. This feature can be combined with Bajie Http's poor CGI handling to execute arbitrary PERL programs. To demonstrate this threat, upload a PERL script using the following URL: http://localhost/upload.html The 'UploadServlet' servlet saves the uploaded file using the client's hostname, IP address, and original file name. Fortunately, the servlet responds with this new file name automatically. Type in the following URL to execute the program: http://localhost/cgi/bin//...//upload/[file name] Bajie Http does not check if a CGI program exists before executing the PERL binary, therefore commands can be passed to a shell if the server is running on a UNIX-based platform. This is done with the following URL: http://localhost/cgi/bin/test.txt;%20[shell command] Solution First vulnerability: Delete all unnecessary servlets. Edit the 'PERLEXECLOC=' line in the 'jzHttpSrv.properties' file to disable CGI support. Second vulnerability: None. Vendor Status The author, Gang Zhang, was initially contacted via [EMAIL PROTECTED] on Saturday, January 27, 2001. Gang verified the vulnerabilities and expressed a willingness to issue a fix. Almost three weeks have passed, and nothing has been released. - Joe Testa ( e-mail: [EMAIL PROTECTED] / AIM: LordSpankatron ) - Begin Hush Signature v1.3 - Hpcq51thWehPYBFyGd6HDfCnQ99EAqSme8Vwa7cz3aoMSMPMacq3Ex+1IA6+8s1kw/xr WwLAemxNnR1toIh9geTpOASqGBrCNhMBBc23AUhdQSs4nZk48CM2zek7V2jz0fXls2Ox ahn5F/A2qkZnq1hIfIMZLt5NG106VI2rQbu6AgDo1kzD7VSZLdF0n7s3kJwcRTCexByQ jtxjCCoP25R9j1WYARl5zlBr2ulwsa9eOz/9UWl/Gq8kGB+CtdNpxSFIoxgO1wu68xY/ fZzicm3uqRyVPpNPpfkCZqmBvdwOpDb03RWL3JkGzzP2s15txISJ31N7IFs8gHLT/6xi eqciatOeTUSPuXWxRqykspEVDcD/e3ku+CR+4eYWOCO1b//P8fu5EBNxEYJy4yOtc+3V uRmBfz/G3WZNM/eoyVjd0kNlXiXTNI4o9MwwYVpT3MsQsEGFuJxowsUNmyYkl7jER1X+ +JKO6ti46HP7KkArhVB960kFMQCqKfhBzfZ0MYmWDmVf - End Hush Signature v1.3 - \n\nThis message has been signed with a Hush Digital Signature. \nTo verify the signature, please go to www.hush.com/tools\n\n
Vulnerability in Resin Webserver
- Begin Hush Signed Message from [EMAIL PROTECTED] - Vulnerability in Resin Webserver Overview Resin 1.2.2 is a webserver available from http://www.caucho.com and http://java.tucows.com. A vulnerability exists which allows a remote user to break out of the web root using relative paths (ie: '..', '...'). Details Resin does in fact check that the requested path lies within the webroot, but by inserting a backslash before any '..' or '...', it is possible to defeat the check. The following URL demonstrates this vulnerability: http://localhost:8080/\../readme.txt Solution A fixed upgrade, 1.2.3, was released and is available at: http://www.caucho.com/download/index.xtp Vendor Status Caucho Technology, Inc was notified via [EMAIL PROTECTED] and [EMAIL PROTECTED] on Sunday, January 28, 2001. I would like to congratulate Caucho for being the first cooperative vendor I have ever dealt with. - Joe Testa ( e-mail: [EMAIL PROTECTED] / AIM: LordSpankatron ) - Begin Hush Signature v1.3 - An0eed7ic2H8Vtwjs3cQulZsm6R8EEwEMFlftmkdq+W6lBV+uEITb9LSwXnLtJGWUwaH ATRTVglHrpuXliZsKdOLkr1V6e+DpfmUpi0EgNnYn0watuvzd1nPfwW7QSXInSdMWuBu KRoEXT3jn3WE4kdyDvbbZ6i8jsN7+mYuSs3JCgELd3t/kumhSfQa7JyxRkO9JUUiJo0q NWSvr5rI60ioW/xv7SS5SGd/Fi9LYKmAPGNRNk86EfTXJsSF5BaogliJT1BvjdOh5Spn Zrng815s3CZweudPh+I7DLmddZefRqpCV6fyp/juittDhpZ9y7WZpy6Ea4LtPfpo07jk tSHqUg2R4cCRJBwj8M+pRGVmfYK1Zhli7AivtznD62DfxEv5abHrPMGwlNabpAc7NHBc 8f7eHUFFTkR0Eb3YAk5y4e+PREaQ6jEbUKS6yIf29Xh6+iZybGssClim0d8SO/2xG5dL tE1WgFJgv1Jd7p+iuXhVu4T65DMhYFi2FluHFYB2g6Gg - End Hush Signature v1.3 - \n\nThis message has been signed with a Hush Digital Signature. \nTo verify the signature, please go to www.hush.com/tools\n\n
Re: Bad PRNGs revisted in FreSSH
* it doesn't _quite_ degenerate to just the code you pasted above; several timings are mixed in, not just at seed time but over the course of the daemon's run. Have you estimated the total entropy supplied by this seeding activity? It needs to be (at the very least) greater than the entropy consumed in generating you're almost comparing apples to oranges here. 1) long term server keys these are usually generated one time: when the software is installed. 2) 'ephemeral' server RSA keys this is the use of the entropy that most people are probably concerned with these days, although these are *typically* generated only once an hour. 3) session keys these are generated by the client. they should have their own sources of entropy, the use of which should not affect the server. and you missed 4) cookies the server sends these to the client to (attempt to) defend against tcp hijacking or ip spoofing. -- |- "CODE WARRIOR" -| [EMAIL PROTECTED] * "ah! i see you have the internet [EMAIL PROTECTED] (Andrew Brown)that goes *ping*!" [EMAIL PROTECTED] * "information is power -- share the wealth."
