Re: [Full-disclosure] Phun! Search
YEAH URE THE BEST I think in the school u learn they call u geek right ? because u act like u understand something ? On 3/24/06, n3td3v [EMAIL PROTECTED] wrote: Read http://en.wikipedia.org/wiki/Hacktivism learn ;-) On 3/24/06, Alexander Hristov [EMAIL PROTECTED] wrote: Im wondering when will u grow up and stop writing shits on FD ? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Best Regards, Aleksander Hristov root at securitydot.net http://securitydot.net ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Sendmail vulnerabilities were released yesterday. No real public announcements to speak of to the security community. Do you live under a rock? There were a lot of public announcements about this. To begin with, anyone noticed the memory leak they (Sendmail) silently patched? I wonder how many other unreported silently-patched vulnerabilities are out there? Yes. There was a presentation at Blackhat Europe about this. It happens all the time. Vendors do not practice responsible disclosure but they expect you to. Sendmail is, as we know, the most used daemon for SMTP in the world. This is an International Infrastructure vulnerability and should have been treated that way. It wasn't. It was handled not only poorly, but irresponsibly. So in one sentence you say that the ISS bug is only a DoS and now you are crying that a bug is being handled irresponsibly? Don't you have already talked to death DNS attacks to sound the alarm about? They say it's a remote code execution. They say it's a race condition. No real data available to speak of. I can't see how it's remotely exploitable, but well, no details, remember? From what we can see it seems like a DoS. So if in the best of your abilities this is only a DoS --- why cry over so called irresponsible disclosure of a bug? Oh wait, the minor memory leak that you think you found is the issue. What they did behind the smoke-screen is replace a lot of setjmp() and longjmp() functions (not very secure ones at that) with goto's (interesting choice). So what would you have done? What smoke-screen are you talking about? The int overflow is possibly exploitable, not very sure about the jumps. No idea why ISS says the Race Condition is, would love insight. You got that right. We would all love you to get some insight. One could say ISS and Sendmail did good, obscuring the information so that the vulnerability-to-exploit time will be longer. That proved wrong, useless and pointless. They failed. Obviously. I mean if *you* couldn't figure out how to exploit the ISS issue then they must have failed. Or wait, you couldn't figure it out so perhaps they failed but are still smarter than you. After looking at the available data for 30 minutes (more or less), we know exactly what the vulnerabilities are. Exploiting them may So after 30 minutes you were wrong about an issue. Tell me again how smart you are. Not to mention the silently patched memory leak. Alert the press. DNS is can be attacked AND there is a memory leak in Sendmail. both ISS and Sendmail should look good and hard at the coming massive exploitation of Sendmail servers. Nah the 1337 h4x0rs will be too busy going after DNS right? With issues relating to the Internet Infrastructure I'd be willing to go even with the evil of non-disclosure, as long as something gets done and then reported publically when it finally scaled down in a roll-back after a couple of years. Yeah, that will work. Because, no offense Mark Dowd, no one else could have found the problem. Well at least we know that the world is safe from you. If not, and you are going to make it public, make the effort and fix it as soon as you can, and give information to help the process of healing. Don't do it a mounth late and obscure data. So if you find a bug, it should be fixed and released on the same day you find it. Yeah right. It took Sendmail a mounth to fix this. A mounth. A whole month? The horror! Babies will die and our women will raped if vendors continue to take an entire month to address as many issues addressed in the Sendmail patch. A mounth! Mounth? So first you say no details should have been released for at least 2 years and now you are crying because it took a month to come up with a patch. Do you even read the shit that seems to flow from your brain to your keyboard? With such Vendor Responsibility, perhaps it is indeed a Good Thing to go Full Disclosure. It seems like history is repeating itself and Full Disclosure is once again not only a choice, but necessary to make vendors become responsible. WTF are you talking about? The bug has been disclosed. The patch released. Why are you complaining? How was Sendmail irresponsible by fixing an issue and releasing a patch? I think you have lost your meds. I wish we could somehow avoid all the guys who will inevitably shout in the press end of the world. The Internet is, was and will stay Except for you right? Answer your phone. Its the kettle calling. Speaking of pot perhaps you should smoke less before sending emails to lists. Have you not shouted about DNS have you not shouted in this tripe filled email about how irresponsible Sendmail and ISS are because the issue is so dangerous and that Sendmail and ISS should watch the mass exploitation that their evil ways will cause? One could hope that someone will take
Re: [Full-disclosure] trusting SMTP [was: SendGate: Sendmail Multiple Vulnerabilities]
On Thu, 23 Mar 2006 03:59:20 CST, Gadi Evron said: Oh, sorry for not mentioning earlier - Operators that want to patch Sendmail, I'd suggest doing it soon. Now we not only do we face risk to our mail servers, but rather trusting other servers as well. Been there, done that. All the same issues we saw when 8.12.9 came out: 8.12.9/8.12.9 2003/03/29 SECURITY: Fix a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable. Problem found by Michal Zalewski. Note: an MTA that is not patched might be vulnerable to data that it receives from untrusted sources, which includes DNS. So just like last time - I'm sure somebody will patch their external-facing mailserver *first*, and that lets exploit mail get through the external mailer and reach the internal mailserver (where before it would just have 0wned the external server). Not that Sendmail is any different from any OTHER infrastructure software. The exact same issues apply when an IOS bug is found, or an NTP bug, or. (And if you think Sendmail didn't do a good job of releasing the info, I shudder to think of what you thought of how Cisco handled the whole Lynn thing ;) pgptz02bQuayi.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] VoIP Security whitepaper : a layered approach
Hi and then there is MGCP/Megaco http://www.sipcenter.com/sip.nsf/html/MGCP+Background cheers Ivan On 3/24/06, Jerome Athias [EMAIL PROTECTED] wrote: Hi Fred, nice paper btw, what about H.323? Regards /JA https://www.securinfos.info - Original Message - From: Frederic Charpentier [EMAIL PROTECTED] Cc: full-disclosure@lists.grok.org.uk Sent: Thursday, March 23, 2006 3:43 PM Subject: [Full-disclosure] VoIP Security whitepaper : a layered approach Hi FD, Our team is pleased to release a whitepaper about VoIP. This whitepaper propose a security analysis of the Voice Over IP protocols with a layered approach. Link : http://www.xmcopartners.com/whitepapers/voip-security-layered-approach.pdf Chapters : 1 VOICE OVER IP SECURITY 1.1 A GENERAL OVERVIEW OF VOICE OVER IP 1.2 VOICE OVER IP PARTICULARITIES 1.3 VOICE OVER IP ARCHITECTURES 1.4 VOICE OVER IP THREATS 1.4.1 Signaling Protocols Layer 1.4.1.1SIP based Denials of Service 1.4.1.2SIP based Man in the Middle/Call Hijacking 1.4.1.3Possible solutions for SIP based attacks 1.4.2 Transport Protocols Layer 1.4.2.1Eavesdropping 1.4.2.2RTP Insertion attacks 1.4.2.3RTCP insertion attacks 1.4.2.4Possible solutions for RTP based attacks 1.4.3Application Layer 1.5 FUTURE THREATS TO VOICE OVER IP SECURITY 2 CONCLUSIONS -- Xmco Partners Security Consulting / Pentest web : http://www.xmcopartners.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Secure HTTP
On Fri, 24 Mar 2006 11:58:35 +0200, Q Beukes said: i just dont want our clear text http traffic to be sniffed which has been a know problem on our network a few times. If the text is something that you give a flying fsck in a rolling donut about the sniffability, it shouldn't be clear text http. Do the frikking SSL correctly on port 443 like the RFCs intend rather than cooking up some half-assed proxy scheme to work around it. insert standard if I had a nickle for every time somebody proposed a partial solution for the wrong part of the problem instead of doing it in the well-understood correct way in the first place, I'd be long since retired speech here pgpm4M3wIKKlM.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Secure HTTP
From: Q Beukes [EMAIL PROTECTED] Subject: Re: [Full-disclosure] Secure HTTP Date: Fri, 24 Mar 2006 11:58:35 +0200 nah. i just dont want our clear text http traffic to be sniffed which has been a know problem on our network a few times. To be honest, if you have an unauthorised network sniffer on your own network then you probably have bigger problems than this. If the sniffer is authorised and is being used to stop network abuse then trying to avoid it would probably be quite obvious. mxb ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] sendmail stuff2
http://rapturesecurity.org/jack/exploiting_sendmail.html has been updated the exploit is just a harness for your ideas, in case you havent noticed, youll need to update the header stuff to make it work. (see url for details). good luck! -- Jack - [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: Re: Re: Links to Google's cache of626FrSIRTexploits
On 3/23/06, Dave Korn [EMAIL PROTECTED] wrote: nocfed wrote: Really, do you ``hackers'' really not know howto at least read the manpage for wget? There is no need for any script, only a few switches to wget. Hint: -e robots=off Wow! j00 R so 1337! Hint: -e clue=on Seriously, I truly phj33r your 4w3s0Me!!!one!1 man-page reading skills, but how could you imagine that switch could possibly make the slightest difference? robots.txt is enforced (or ignored) by the client. If a server returns a 403 or doesn't, depending on what UserAgent you specified, then how could making the client ignore robots.txt somehow magically make the server not return a 403 when you try to fetch a page? If you think that a switch that makes no difference to the data going over the wire could affect the response given to an otherwise identical protocol request sent back by the server, you must think they're using IP over ESP as a transport layer. Which rfc was that again? Or perhaps you just don't understand the first thing about the client-server model of system architecture. In which case you're in no position to go around calling other people hackers in sarcastic quote marks[*]. Anyway, this is a great illustration of the dangers of posting smartarse replies without actually having TRIED what you claim will work. Let me *prove* it: here's what happens if you try and wget the list of cached page, first with no switches, then with -e but no -U, then with -U but no -e. You have failed to understand the 'hint' part. It was a hint at ONE of the switches to use.. As you apparently have not read the manpage for wget, here is the full command. wget -e robots=off -Hr -nd -np --domains=72.14.203.104 -U Mozilla http://www.elsenot.com/frsirt-google.html Now please go snarf down the interweb. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] help about tool to control x window client (xterm) script-like way
hi, In our research, we need to generate some X traffic through network. The current approach is let human actor sit manipulate a xterm window to type keys, move mouse, resize window. Is there any tool that can automatically do this? The ideal one might trigger key press, button press, window change event following a pre-defined script file. We have used Expect package to do it for normal TELNET, SSH traffic. But Expect can not control X window Client. Any suggestion is welcome. Thanks. Regards, yours, jqxin2006 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Secure HTTP
Wait, you mean security (solely) through obscurity doesn't work?? :) /TJ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Ng Sent: Friday, March 24, 2006 10:43 AM To: [EMAIL PROTECTED] Cc: Full Disclosure Subject: Re: [Full-disclosure] Secure HTTP On 3/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Do the frikking SSL correctly on port 443 like the RFCs intend rather than cooking up some half-assed proxy scheme to work around it. insert standard if I had a nickle for every time somebody proposed a partial solution for the wrong part of the problem instead of doing it in the well-understood correct way in the first place, I'd be long since retired speech here You would be more than rich. You won't believe the number of security improvements I've had to knock down. One application had all the ports reassigned to all non standard ports. When I asked why such a brain dead thing was done, they said it was for security, and that it would be too much work to find these ports. Then I showed them nmap with the port identification option. Their jaw dropped to the floor. They had *NO* security. Anonymous ftp world writable, http with no id or password allowing web page updating, telnet with no id or password. Needless to say, a redesign was required. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] formatfun
Hello, mod_ssl: /httpd-2.0.48/modules/ssl/ssl_engine_kernel.c (also in 2.0.55) proto: ap_log_error(constchar*file,intline,intlevel,apr_status_tstatus,constserver_rec*s,constchar*fmt,...) code: ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, buff); is this exploitable? sendmail 8.13.5: sendmail-8.13.5/sendmail/main.c proto: sm_setproctitle(boolstatus,ENVELOPE*e,constchar*fmt,...) code: sm_setproctitle(true, CurEnv, qtype); _NOT_ exploitable because sendmail DROPS PRIVILEGES! mailqueue anyone? openssh-4.0p1: file: openssh-4.0p1/openssh-4.0p1/auth1.c proto: packet_disconnect(constchar*fmt,...) code: packet_disconnect(msg); i guess thats not exploitable since msg is not user supplied. any pointers from the list? - - kcope ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] help about tool to control x window client (xterm) script-like way
On Fri, 24 Mar 2006 09:52:30 CST, Jianqiang Xin said: In our research, we need to generate some X traffic through network. The current approach is let human actor sit manipulate a xterm window to type keys, move mouse, resize window. Is there any tool that can automatically do this? The ideal one might trigger key press, button press, window change event following a pre-defined script file. We have used Expect package to do it for normal TELNET, SSH traffic. But Expect can not control X window Client. You're looking for something that uses the XTEST extension to the X protocol. http://wiki.x.org/wiki/TestGroup will probably get you started. pgp6OuNZAKkJS.pgp Description: PGP signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] [DDSi-SA] XSS in Raindance Communications Web Conferencing Pro
-= DDSi Security Advisory =- March 24, 2006 Vendor: Raindance Communications, Inc. Raindance offers audio and web conferencing solutions for more effective web meetings. Integrated web, audio and internet video conferencing makes online meetings and webinars easier and more productive. Product: Raindance Web Conferencing Pro. Vulnerability : XSS in browser compatibility check. Meeting requests may be sent to unsuspecting party with malicious code. Location: http://company.raindance.com/check/failed? browser=1:%3Cscript%3Ewindow.alert(%22a%22)%3C/script%3E passedurl=/iccdocs/passedtest.shtml Vendor communication history: March 13 initial contact ( webmaster ) March 16 second attempt contact techsupport March 17 automatic ticket opened March 23 still no techsupport engineer assigned. Email asking for status sent. March 24. No response. Public release. Dimitry Snezhkov. DDSi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] FrSIRT Puts Exploits up for Sale
FrSIRT is officially pointing to local laws now; their Exploits section redirects to the following statement In conformity with applicable French laws prohibiting Full-disclosure including link to the official legifrance.gouv.fr document. http://www.frsirt.com/exploits/ - Juha-Matti ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] FrSIRT Puts Exploits up for Sale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wonder if they pay for undisclosed (but patched) exploits or are they just hey gimme your poc I will do business with it :) Juha-Matti Laurio wrote: FrSIRT is officially pointing to local laws now; their Exploits section redirects to the following statement In conformity with applicable French laws prohibiting Full-disclosure including link to the official legifrance.gouv.fr document. http://www.frsirt.com/exploits/ - Juha-Matti ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ __ NOD32 1.1456 (20060323) Information __ This message was checked by NOD32 antivirus system. http://www.eset.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) iD8DBQFEJDBhFJS99fNfR+YRAo+iAJ9owm51sb7TmcunYi8UJfjKpmE0HACdGNLQ /piDGznaNOnFBn+TRexaB3c= =Q8M1 -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] FrSIRT Puts Exploits up for Sale
I would rather say that they are using the law as an excuse, since they could have gotten the DB with all the exploits host in another country. Just my oppinion /Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha-Matti Laurio Sent: Friday, March 24, 2006 6:14 PM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] FrSIRT Puts Exploits up for Sale FrSIRT is officially pointing to local laws now; their Exploits section redirects to the following statement In conformity with applicable French laws prohibiting Full-disclosure including link to the official legifrance.gouv.fr document. http://www.frsirt.com/exploits/ - Juha-Matti ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
I have to comment on these allegations by Gadi Evron.
Tech details:
Sendmail vulnerabilities were released yesterday. No real public
announcements to speak of to the security community.
Sendmail, CERT, and ISS Advisories went out. That's not a real
public announcement?
SecuriTeam released some data:
Improper timeout calculation, usage of memory jumps and integer
overflows allow attackers to perfom a race condition DoS on
sendmail, and may also execute arbitrary code.
More here: http://www.securiteam.com/unixfocus/5RP0L0UI0S.html
ISS only reported the Race Condition (DoS?). The Sendmail Advisory
reported the Race Condition DoS, the Memory Jumps and a
theoretical Integer Overflow.
To begin with, anyone noticed the memory leak they (Sendmail)
silently patched?
I wonder how many other unreported silently-patched
vulnerabilities are out there?
There was no memory leak. Look at the code referred to by SecuriTeam
(see http://www.securiteam.com/unixfocus/5SP0M0UI0G.html):
/* clean up buf after it has been expanded with args */
newstring = str2prt(buf);
if ((strlen(newstring) + idlen + 1) SYSLOG_BUFSIZE)
{
...
if (buf == buf0)
buf = NULL; - Memory leak
errno = save_errno;
return;
}
The part they conveniently left out is that buf0 is a local variable.
If buf == buf0 then you don't need to free it --- freeing it would,
in fact, be a bug. This should be obvious to anyone looking at the
code.
Second, the Integer Overflow is practical, not theoretical.
It is theoretical because the routines in question (rewrite() and
rscheck()) are part of the rewriting engine, which always takes a
fixed size buffer as input. There just isn't a way for the overflow
to ever occur. We fixed it because it was the right thing to do.
ISS reported the Race Condition last mounth. There is NO data
available on when the other vulnerabilities were discovered. Any
guesses?
The memory jumps is part of the race condition, not a separate
problem. The integer overflow problem came to our attention shortly
thereafter.
They also patched many non-security related bugs, added checks and
more informative error messages, etc.
In 8.13.6? Are you suggesting that it is irresponsible of us to
continue to develop code? If you want just the security patch, apply
the security patch, which we made available at the same time.
Sendmail is, as we know, the most used daemon for SMTP in the
world. This is an International Infrastructure vulnerability and
should have been treated that way. It wasn't. It was handled not
only poorly, but irresponsibly.
Here's what ISS releasing the Race Condition vulnerability has to
say: http://xforce.iss.net/xforce/alerts/id/216
They say it's a remote code execution. They say it's a race
condition. No real data available to speak of. I can't see how it's
remotely exploitable, but well, no details, remember? From what we
can see it seems like a DoS.
To be blunt, we don't understand much more about it than all of you
do. It is an extremely subtle problem that involves making an alarm
signal occur in a very small section of code as the result of a
multi-minute timeout. The signal causes a longjmp that can leave a
piece of code in an inconsistent state. ISS explained it to us and
told us that they had managed to craft an exploit in their lab, but
frankly we don't see how it can be practical. This literally
requires nanosecond precision in the millisecond world of networking.
Bottom line
---
What they did behind the smoke-screen is replace a lot of setjmp()
and longjmp() functions (not very secure ones at that) with goto's
(interesting choice).
There's a big difference between a synchronous goto in a single
context versus an asynchronous longjmp() between contexts.
They changed the logic of the code, replaced everything that
calculated timeout. Anything that calculated something and returned
a value now returns a boolean result, when previously they just
returned void. They used to look at the content rather than success.
When we got rid of the longjmp() we had to propagate I/O errors the
hard way --- as return values. This involved adding a lot of
checking. Painful, but necessary.
The int overflow is possibly exploitable, not very sure about the
jumps. No idea why ISS says the Race Condition is, would love
insight.
I've already commented on this.
Public announcement
---
FreeBSD were the only ones who released a public announcement of a
patch and emailed it to bugtraq so far.
Talk to the vendors. I've seen quite a few of their advisories come
by.
The patches
---
The FreeBSD patch much like the sendmail.org patch is very long,
complicated and obscure. The release was made along with a ton of
other patches for FreeBSD. Go figure what's in there.
FreeBSD updated to 8.13.6 rather than using 8.13.5+patches. This is
what we are recommending for everyone.
Sendmail.com's patch is so big they may as well
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Sucks to be held accountable, even when you give stuff away for free, doesn't it? We hold ourselves very accountable. Every day we try to make code better. How's that for accountability, (who are you again?) That does not make it right for our user community to attack developers for their freely given efforts. People who get attacked might stop trying to improve the code. You could run other software, you know. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Secunia Research: Quick 'n Easy/Baby Web Server ASP Code Disclosure Vulnerability
== Secunia Research 24/03/2006 - Quick 'n Easy/Baby Web Server ASP Code Disclosure Vulnerability - == Table of Contents Affected Software1 Severity.2 Description of Vulnerability.3 Solution.4 Time Table...5 Credits..6 References...7 About Secunia8 Verification.9 == 1) Affected Software * Quick 'n Easy Web Server version 3.0.6 and 3.1 * Baby Web Server version 2.7.2 Prior versions may also be affected. == 2) Severity Rating: Moderately Critical Impact: Exposure of sensitive information Where: Remote == 3) Description of Vulnerability Secunia Research has discovered a vulnerability in Quick 'n Easy/Baby Web Server, which can be exploited by malicious people to disclose potentially sensitive information. The vulnerability is caused due to a validation error of the filename extension supplied by the user in the URL. This can be exploited to retrieve the source code of ASP files from the server via specially crafted requests containing dot, space and slash characters. == 4) Solution Quick 'n Easy Web Server: Update to version 3.1.1 http://www.pablosoftwaresolutions.com/html/quick__n_easy_web_server.html Baby Web Server: The vendor has reported that Baby Web Server is not longer supported and has been replaced with Quick 'n Easy Web Server. == 5) Time Table 22/03/2006 - Initial vendor notification. 22/03/2006 - Initial vendor reply. 24/03/2006 - Public disclosure. == 6) Credits Discovered by Tan Chew Keong, Secunia Research. == 7) References No other references. == 8) About Secunia Secunia collects, validates, assesses, and writes advisories regarding all the latest software vulnerabilities disclosed to the public. These advisories are gathered in a publicly available database at the Secunia website: http://secunia.com/ Secunia offers services to our customers enabling them to receive all relevant vulnerability information to their specific system configuration. Secunia offers a FREE mailing list called Secunia Security Advisories: http://secunia.com/secunia_security_advisories/ == 9) Verification Please verify this advisory by visiting the Secunia website: http://secunia.com/secunia_research/2006-19/advisory/ Complete list of vulnerability reports published by Secunia Research: http://secunia.com/secunia_research/ == ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RE: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Finally PEOPLE speak the TRUTH Well said!! -Original Message- From: Theo de Raadt [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 9:52 PM To: Gadi Evron Cc: bugtraq@securityfocus.com; full-disclosure@lists.grok.org.uk Subject: Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow) Sendmail is, as we know, the most used daemon for SMTP in the world. This is an International Infrastructure vulnerability and should have been treated that way. It wasn't. It was handled not only poorly, but irresponsibly. You would probably expect me to the be last person to say that Sendmail is perfectly within their rights. I have had a lot of problems with what they are doing. But what did you pay for Sendmail? Was it a dollar, or was it more? Let me guess. It was much less than a dollar. I bet you paid nothing. So does anyone owe you anything, let alone a particular process which you demand with such length? Now, the same holds true with OpenSSH. I'll tell you what. If there is ever a security problem (again :) in OpenSSH we will disclose it exactly like we want, and in no other way, and quite frankly since noone has ever paid a cent for it's development they have nothing they can say about it. Dear non-paying user -- please remember your place. Or run something else. OK? Luckily within a few months you will be able to tell Sendmail how to disclose their bugs because their next version is going to come out with a much more commercial licence. Then you can pay for it, and then you can complain too. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On Thu, 23 Mar 2006, Dragos Ruiu wrote: On March 23, 2006 01:41 am, Gadi Evron wrote: Here's what ISS releasing the Race Condition vulnerability has to say: http://xforce.iss.net/xforce/alerts/id/216 They say it's a remote code execution. They say it's a race condition. No real data available to speak of. I can't see how it's remotely exploitable, but well, no details, remember? From what we can see it seems like a DoS. ISS's Mark Dowd is very clever guy. And if duke says it's exploitable I would believe him :-). It's an interesting new vector anyway. Indeed, which is why I said I can't see how and asked for details, as well as in the next paragraoph that I would be happy to be enlightened. :) But like all timing related attacks, the question is reliability. Though gossip has it, this one is repeatable with sub-100 attempts and you get infinite shots at it because even if the process does die it's a child of the parent listener. (So it is not really a DoS per se in any case.) Bottom line --- What they did behind the smoke-screen is replace a lot of setjmp() and longjmp() functions (not very secure ones at that) with goto's (interesting choice). Smoke screen seems like unfarily loaded terminology to use. OpenBSD fixed (removed) many setjmp/longjmp functions in their tree a long time ago as a class of bugs. (Though this sendmail exploitable collecttimeout() longjmp one is new and they patched it yesterday with everyone else, because as you noted, replacing it was kinda hairy...) I don't think its fair to bitch about people fixing bugs and then not having the time to send out advisories for every little tweak. The important thing is to fix the bug. And often times the developer won't understand the real impact of fixing a bug until someone clever like Mark comes up with some innovative way to exploit an unexploitable bug like this one. I would tend to agree, however, sendmail have been very irresponsible in the past, and with all due respect, if they want to play at being critical internet infrastructure, they should live up to expectations or find a new game. What will be interesting to see when the PoC exploits are finally released, is if any of the memory/stack protection schemes mitigate it. humor Besides, there is only one true mailer to mail them all, and its name is Postfix. /humor :) Now if we could only convince Mr. Venema to switch to a BSD license _everyone_ would switch to Postfix and everything would be much better. If it weren't for that poison pill clause in its license, I'm sure most OSes and commercial systems would have swapped out Sendmail for Postfix long ago. I agree, Postfix is incredibly good.. once you learn to get along with it! cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, CanadaApril 3-7 2006 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] trusting SMTP [was: SendGate: Sendmail Multiple Vulnerabilities]
On Fri, 24 Mar 2006 [EMAIL PROTECTED] wrote: On Thu, 23 Mar 2006 03:59:20 CST, Gadi Evron said: Oh, sorry for not mentioning earlier - Operators that want to patch Sendmail, I'd suggest doing it soon. Now we not only do we face risk to our mail servers, but rather trusting other servers as well. Been there, done that. All the same issues we saw when 8.12.9 came out: Exactly. You just made my point. 8.12.9/8.12.9 2003/03/29 SECURITY: Fix a buffer overflow in address parsing due to a char to int conversion problem which is potentially remotely exploitable. Problem found by Michal Zalewski. Note: an MTA that is not patched might be vulnerable to data that it receives from untrusted sources, which includes DNS. So just like last time - I'm sure somebody will patch their external-facing mailserver *first*, and that lets exploit mail get through the external mailer and reach the internal mailserver (where before it would just have 0wned the external server). Not that Sendmail is any different from any OTHER infrastructure software. The exact same issues apply when an IOS bug is found, or an NTP bug, or. (And if you think Sendmail didn't do a good job of releasing the info, I shudder to think of what you thought of how Cisco handled the whole Lynn thing ;) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On Thu, 23 Mar 2006, Theo de Raadt wrote: Sendmail is, as we know, the most used daemon for SMTP in the world. This is an International Infrastructure vulnerability and should have been treated that way. It wasn't. It was handled not only poorly, but irresponsibly. You would probably expect me to the be last person to say that Sendmail is perfectly within their rights. I have had a lot of problems with what they are doing. But what did you pay for Sendmail? Was it a dollar, or was it more? Let me guess. It was much less than a dollar. I bet you paid nothing. So does anyone owe you anything, let alone a particular process which you demand with such length? So you are basically saying open source free software can't be trusted to hold high standards or be reliable or secure if I don't pay for it? Now, the same holds true with OpenSSH. I'll tell you what. If there is ever a security problem (again :) in OpenSSH we will disclose it exactly like we want, and in no other way, and quite frankly since noone has ever paid a cent for it's development they have nothing they can say about it. Dear non-paying user -- please remember your place. Or run something else. OK? Luckily within a few months you will be able to tell Sendmail how to disclose their bugs because their next version is going to come out with a much more commercial licence. Then you can pay for it, and then you can complain too. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
On Thu, 23 Mar 2006, Eric Allman wrote: snip mostly relevant good replies by Mr. Allman Talk to the vendors. I've seen quite a few of their advisories come by. After or before it hit the news? You may be able to alert vendors, but the problem with critical infrastructure is that is widely deployed around the world. Releasing the way you did is irresponsible. You can do non-disclosure for a while or full disclosure, you can't do both. Commentary == personal opinion Yes, that's true. If it's exploitable and people don't update, then those people who choose to ignore the problem will be vulnerable. You could say that about every vulnerability that has ever existed. Indeed. And yet blaming the user is not how you solve the problem, is it? The Internet being insecure is a give, do you blame the Internet for telnet not being secure, or do you create SSH? How long before enough Sendmail servers globally are patched? A mounth! Are you suggesting that it would have been better for us to have released the problem without giving vendors any time at all to get it integrated? I think that would be seriously irresponsible. I agree, my point is that if you release, do it as soon as you can as you ARE critical infrastructure. If you want to let vendors get something done, wait a whole lot longer than a month. Gadi. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: PasswordSafe 3.0 weak random number generator allows key recovery attack
Markus Jansson wrote: 3) Is there a fix available? Considering PasswordSafe 3.0 is still in beta, I imagine they'll fix this one before actually /releasing/ the software... cheers, DaveK -- Can't think of a witty .sigline today ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
So you are basically saying open source free software can't be trusted to hold high standards or be reliable or secure if I don't pay for it? I don't think his argument had anything to do with open source. He was talking about payment, or lack thereof. You can give away binaries for free as well. And I'm not implying that the rest of your conclusions about his statement is accurate, either. Just had to point out that one flaw. tim ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
[EMAIL PROTECTED] wrote: Posting a private email to a mailing list is pretty slimeball Ryan. And what private email was that? Or did you just assume that because you didn't see Theo's reply before mine that it went just to me? I believe you'll find that it has been posted to the list now. BB P.S. It's rather amusing that YOU would complain about someone posting private emails. :) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Gadi Evron wrote: So you are basically saying open source free software can't be trusted to hold high standards or be reliable or secure if I don't pay for it? No, he's saying: If you know a better way why don't you do it instead of yapping about what's wrong. Theo does have the chat skills of a rhinoceros in heat but he does have a point. If his project is mis-managed you're free to fork and do it better. So if you know better then either contribute, create something better or be ignored. It's bsd, just download the source, fix the problems and release a better version. That way you'd contribute, instead of just yap. -- // hdw ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] FrSIRT Puts Exploits up for Sale
Im very surprised too On 3/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I would be suprised to see a law that says it is bad to give other peoples work away for free but ok to sell that work? Something doesn't smell right in France and its not the cheese. On Fri, 24 Mar 2006 10:16:06 -0800 CIRT.DK Mailinglists [EMAIL PROTECTED] wrote: I would rather say that they are using the law as an excuse, since they could have gotten the DB with all the exploits host in another country. Just my oppinion /Dennis -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Juha-Matti Laurio Sent: Friday, March 24, 2006 6:14 PM To: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] FrSIRT Puts Exploits up for Sale FrSIRT is officially pointing to local laws now; their Exploits section redirects to the following statement In conformity with applicable French laws prohibiting Full- disclosure including link to the official legifrance.gouv.fr document. http://www.frsirt.com/exploits/ - Juha-Matti ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ -- Best Regards, Aleksander Hristov root at securitydot.net http://securitydot.net ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Re: SendGate: Sendmail Multiple Vulnerabilities (Race Condition DoS, Memory Jumps, Integer Overflow)
Theo de Raadt wrote: After or before it hit the news? You may be able to alert vendors, but the problem with critical infrastructure is that is widely deployed around the world. Releasing the way you did is irresponsible. Taking our freely available software and creating a mono-culture is something that the administrators did. We don't get paid (or we don't get paid enough). I see, so why don't you go work for commercial vendors? With that kind of security attitude I wonder why anybody believes OpenBSD is the most secure OS around. Most arguments against open source in big organizations are that they have no backing, serious tech support, etc. That brought about a myriad of third-party companies which provide with this service. I often find open source to be a lot more responsive than many commercial companies, but it's still done based on good will and free time. That doesn't scale well in the board room. You better quit now as you are making a horrible attempt at protecting open source, which I strongly believe in. If a commercial giant * up, or an open source product does, makes no difference to me. When people say: you can't comment unless you go and do on your own, move along. People will move along. Sometimes I will ignore input from non-contributors,. but ignoring input, especially of the critical type, from your users makes you not suitable for these users or to grow and scale as something for the infrastructure. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
