[Full-disclosure] G+ app steals images
FYI, G+ app on Android just steals any images you make using camera. I just made photo using camera and minute later it appeared on https://lh4.googleusercontent.com/-5ep3-OdJSCY/TqTL05oMWzI/As4/luE-w5IE3ZE/s800/DSC_0107.JPG without my permission. Google claims that this image is visible only to me. Clearly this is not true. Tonu ___ 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] Barracuda backdoor
> Let's be careful though: just because your system stopped working > doesn't mean it has a backdoor. It could have been implemented as simply > a periodic "phone home for updates" which received some type of > "license expired" message. A remote kill switch, for sure, but not > necessarily the same as a back door. For now I have reports from people who do not want to expose them but claim that Barracuda people can freely log in into their systems but never asked for password etc. This time I have no proof etc. Just I get lot of different pieces of feedback in private. Tõnu ___ 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] Barracuda backdoor
On Thu, 2011-04-28 at 17:05 +0100, corpus.defero wrote: > On Thu, 2011-04-28 at 08:29 -0700, ichib0d crane wrote: > (snipped) > > but that doesn't > > change the fact that Barracuda has done something likely bad here. A > > vendor should make it explicitly clear when they have the capability > > to disable remote products that have already been purchased. Maybe > > their ToS allows it, maybe not. Either way it is highly unethical. > > > They can't. All they can do is disable updating of the virus and spam > definitions. It will still work without a subscription to 'energize > updates'. Reread topic again. This is exactly what they did - they disabled essentially needed features of customer property, unrelated to annual subscription. Also this is less important in my opinion but actually all bills were paid which removes even last options to make customer guilty here. I would really be angry is BMW remotely disables my car because they have some civil disagreement with local service center for example. Tõnu ___ 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] Barracuda backdoor
On Thu, 2011-04-28 at 12:09 -0400, valdis.kletni...@vt.edu wrote: > On Thu, 28 Apr 2011 13:09:14 +0300, =?ISO-8859-1?Q?T=F5nu_Samuel?= said: > > > One day their Barracuda product stopped working. > > OK... That's hardly surprising, given the high-quality software engineering > that Barracuda is known for.. ;) > > > Barracuda not only disabled all kind of subscription services but also > > used some kind of backdoor in their products to disable product customer > > had paid long time ago. > > And I should believe this claim, why? > Sue me. Sometime such claim is good enough because they will not sue me. And if they do, this makes me happy. I got sued multiple times for what I say in public and I never lost the case yet. > Now the question is - given that *that* Barracuda was at least semi-functional > even when off support, do we have any indication that your unit was in fact > intentionally disabled? It could very well be the symptoms you are seeing are > the unit being just plain *broken*. Yes I do have proofs, including Barracuda mails confirming it. There are multiple of them including this one: From: Chelsi Newland [mailto:cnewl...@barracuda.com] Sent: Wednesday, April 27, 2011 5:51 PM Subject: FW: Current (Expires 2011-11-21) Importance: High Please note we have proof of payment to you from the end user. Either reimburse this customer, or send payment for this order. Please advise payment on your account so we can enable their unit. Sincerely, Chelsi Newland| Barracuda Networks | Credit/Collections Manager Tõnu ___ 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] Barracuda backdoor
On Thu, 2011-04-28 at 12:59 +0200, Christian Sciberras wrote: > Oh I'm sure someone on the list is going to help you. > Just give us SSH and root access and we'll do the hard work for you. > See, that's being open, not closed...! Sure someone can do. I happen to know some people who are able to reverse engineer anything on PC but they are busy doing useful stuff instead of proving someones bad intentions in Barracuda. To me it looks like only correct way for Barracuda is to issue clear statement that they remove all such "features" from their products and and issue free patch for this. And yes, I am sure if Barracuda will act to hide problem we soon see what else community find out. World is weird. I happen to write review on all Barracuda product line at same time. I will praise their product as "works of out of box" and meanwhile I do not recommend such timebomb into server room but pay some guy to configure postfix with all proper addons instead. Also this fact already changed two "go" desicions from Barracuda to "no-go" ones in my close contacts. Tõnu ___ 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] Barracuda backdoor
On Thu, 2011-04-28 at 11:45 +0100, Benji wrote: > Do you actually have any evidence of a backdoor? Or could this just be > a remote 'turn-off' switch as such? I'm not saying that one is better > than the other, but they are very different features. I have no idea how this technically is implemented or what they can do else. This is clear example of closed source product dangers. Today we found some "switch off", tomorrow what? How we can be sure about anything? Only thing I am sure now: they kept copy of keys to house you bought from them years ago and their used those keys for illegal thing. Tõnu ___ 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] Barracuda backdoor
Hello! We have alarming case with Barracuda products here. Customer bought Barracuda hardware years ago and paid for it. No leasing etc. Product is Barracuda Spam Firewall 800 which is $40k product. Customer also paid for not-so-cheap annual subscription fees each year. One day their Barracuda product stopped working. After investigating problem it came out that Barracuda reseller and Barracuda itself have some misunderstandings and because of this Barracuda not only disabled all kind of subscription services but also used some kind of backdoor in their products to disable product customer had paid long time ago. Message was shown "Error: Activation has not been completed. Please activate your Barracuda Spam & Virus Firewall to enable functionality. (Click here to activate)". Customer was blocked to make any changes in admin interface of product. Even more irritating was fact that admin wanted to see why some e-mails were lost and was denied even to see logs! Notice - Barracuda have not just disabled some online services (which were paid too) but they remotely disabled hardware product which does not belong to them. I think users should be warned for companies like Barracuda. As much I understand this is also criminal violation to sabotage some other company network resources. Tõnu ___ 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] Speakers Required for null+h4ck3r meet in Delhi on 31st July 2010
On Wed, 2010-07-28 at 11:26 +0530, Rockey Killer wrote: > Hello Friends, > > Dates are coming closer and we all are going to meet once again :) . > > Just a remainder about the meet > > Time : 4 - 7 P.M > Date : 31st July 2010 (Saturday) > Venue : > USO House, USO Road, > Off Shaheed Jeet Singh Marg, > 6, Special Institutional Area, > New Delhi-110067 Don't tell the country :P Tõnu ___ 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] Cross-Site Scripting attacks via redirectors in different browsers
> I wrote about five method of attacks in the article (via location-header and > refresh-header redirectors) - about four of them I already posted in > Bugtraq. In this letter I'll inform you about new vulnerable browsers to > those vulnerabilities which I wrote to Bugtraq before. Thanks, useful info for me at least. And do not forget, this is feature, not bug :P Tõnu ___ 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] Distribution of passwords between man and women
On Tue, 2009-09-15 at 14:24 +0200, Anıl Kurmuş wrote: > 99% confidence interval > for men: 1.65 to 1.73% (use lastname as a password, granted) > women : 1.36 to 1.52% > > seems like there is a difference, but not very significant imo :) But 123456 usage was different enough. Of course my results are disputable. Just found it interesting and now also waiting for someone else to confirm this or come out with competing theory or database stats. Tõnu ___ 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] Distribution of passwords between man and women
Hi all kind of bad people in this list. Want to share weird thing I discovered today: Men have MUCH worse passwords than females. There is a user database where men to woman ratio is 5.2:1 but men but use last name more often as password. Ratio is 6.2:1. When it somes to bad password like "123456", men used it on 9.3:1 ratio. More details I put on page: http://no.spam.ee/~tonu/passwords.html If you want me run more queries on this DB, mail me in private back and publish them too on same page. Tõnu ___ 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] Oracle and Citibank cooperation
Hi! I highly suggest watching Oracle Web Conferences. They are public, free and contain lot of "interesting" information. Just one shot: http://no.spam.ee/~tonu/oracle-citibank-ssl.png Tõnu ___ 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] Intel Core 2 CPUs are buggy. Patch your cpus :D
Seems we may soon see some "interesting" problems: -- "Various developers are busy implimenting workarounds for serious bugs in Intel's Core 2 cpu. These processors are buggy as hell, and some of these bugs don't just cause development/debugging problems, but will *ASSUREDLY* be exploitable from userland code. As is typical, BIOS vendors will be very late providing workarounds / fixes for these processors bugs. Some bugs are unfixable and cannot be worked around. Intel only provides detailed fixes to BIOS vendors and large operating system groups. Open Source operating systems are largely left in the cold. Full (current) errata from Intel: http://download.intel.com/design/processor/specupdt/31327914.pdf - We bet there are many more errata not yet announced -- every month this file gets larger. - Intel understates the impact of these erraata very significantly. Almost all operating systems will run into these bugs. - Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58). - Some of these bugs are along the lines of "buffer overflow"; where a write-protect or non-execute bit for a page table entry is ignored. Others are floating point instruction non-coherencies, or memory corruptions -- outside of the range of permitted writing for the process -- running common instruction sequences. - All of this is just unbelievable to many of us. An easier summary document for some people to read: http://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell out of us. Some of these are things that cannot be fixed in running code, and some are things that every operating system will do until about mid-2008, because that is how the MMU has always been managed on all generations of Intel/AMD/whoeverelse hardware. Now Intel is telling people to manage the MMU's TLB flushes in a new and different way. Yet even if we do so, some of the errata listed are unaffected by doing so. As I said before, hiding in this list are 20-30 bugs that cannot be worked around by operating systems, and will be potentially exploitable. I would bet a lot of money that at least 2-3 of them are. For instance, AI90 is exploitable on some operating systems (but not OpenBSD running default binaries). At this time, I cannot recommend purchase of any machines based on the Intel Core 2 until these issues are dealt with (which I suspect will take more than a year). Intel must be come more transparent. (While here, I would like to say that AMD is becoming less helpful day by day towards open source operating systems too, perhaps because their serious errata lists are growing rapidly too)." Source: http://marc.info/?l=openbsd-misc&m=118296441702631&w=2 ___ 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] Month of Random Hashes: DAY THREE
On Wed, 2007-06-13 at 23:16 -0700, Brian Dessent wrote: > Hashing is not encryption, so flush the notion of "decrypt a hash" from By definition hashing stuff is also encryption. Not reversible but as art it is can be categorized under "encryption" :) > But seeing as this is FD and there has been a rash of "Month of Foo" > nonsense, I think someone is just taking the piss and further degrading > the already miniscule SNR of this list. Unless a posted hash is > correlated to the release of some POC or other item of interest, it's > noise. Actually author who posted those hashes are known man and I am sure if he posted something, this is cool and I am really sitting and waiting what he have found. Also I know that he usually provides POC after 6 or 12 months AT LEAST, so do not expect fast info. Tõnu ___ 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] [Fwd: Re: Apache Illegal Request Handling Possible XSS Vulnerability]
oops, missed the CC to list
--- Begin Message ---
On Tue, 2007-04-24 at 11:24 +0200, Guasconi Vincent wrote:
> echo htmlentities($_SERVER['REQUEST_METHOD']);
> echo htmlentities($_SERVER['SERVER_PROTOCOL']);
> ?>
>
> Sorry but,
> where's the hole? (^-^)
Hole is that you still can pass utf7 through it. htmlentities know
nothing about context encoding.
echo "alert('BEeF');" | iconv -f utf8 -t utf7
+ADw-script+AD4-alert('BEeF')+ADsAPA-/script+AD4
Tõnu
--- End Message ---
___
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] Firefox 2.0.0.3 DoS crash
On Thu, 2007-04-19 at 20:22 +0200, carl hardwick wrote: > Firefox 2.0.0.3 DoS crash > > PoC: > chrome://pippki/content/editcacert.xul > chrome://pippki/content/editemailcert.xul > chrome://pippki/content/editsslcert.xul Works for me on Linux when clicking on such link. Meanwhile I tried to embed it into webpage and did not work. [EMAIL PROTECTED]:~/Desktop> cat poc.html [EMAIL PROTECTED]:~/Desktop> ___ 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] RainbowCrack-Online
On Mon, 2007-03-26 at 10:41 -0400, T Biehn wrote: > Hello Full Disclosure, > John Harrison has cut off communication with me after breaking lot of cry removed. > Regards, > > Travis Biehn Where is disclosure? Courts are for this matter. http://barkingmadly.blogspot.com/2006/09/travis-biehn-wins-on-appeal.html Tõnu ___ 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] firefox 2.0.0.2 crash
Can be dupe but in fast browsing over topics I did not discovered this exploit: http://people.zoy.org/~sam/firefox-crash-save-session-before-clicking.gif I do NOT know anything else than this url. Just seen it in random discussion and anyone else I asked knows nothing. Current tests indicate that Mozilla 2.0.0.2 gets killed within second, 1.5.0.10 survives. Tõnu ___ 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] Fwd: Re: Universal XSS with PDF files: highly dangerous
Oops, please discart previous post author. I used wrong profile in home
desktop :P
-- Forwarded Message --
Subject: Re: [Full-disclosure] Universal XSS with PDF files: highly dangerous
Date: Friday 05 January 2007 15:53
From: Kristina Lein <[EMAIL PROTECTED]>
To: full-disclosure@lists.grok.org.uk
Cc: "pdp (architect)" <[EMAIL PROTECTED]>,
bugtraq@securityfocus.com, "Web Security" <[EMAIL PROTECTED]>
On Wednesday 03 January 2007 04:20, pdp (architect) wrote:
> I will be very quick and just point to links where you can read about
> this issue.
>
> It seams that PDF documents can execute JavaScript code for no
> apparent reason by using the following template:
>
>
> http://path/to/pdf/file.pdf#whatever_name_you_want=javascript:your_code_her
>e
>
> You must understand that the attacker doesn't need to have write
> access to the specified PDF document. In order to get an XSS vector
> working you need to have a PDF file hosted on the target and that's
> all about it. The rest is just a matter of your abilities and desires.
Even more, maybe it is possible to modify content of PDF with this method.
Some way (I have not tried though) described here;
http://www.planetpdf.com/developer/article.asp?ContentID=6904
Need to write POC
Also I have to tell that my firefox crashed when I appended some random
document.write('foobar') to exploit. I suppose it wrote it to PDF memory?! In
this case we maybe can also execute code? Scary.
Tõnu
---
___
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] Pincone Research Clipboard Access
y0himba wrote: The have implemented a "security feature" that attempts to access my clipboard. I of course don't want to allow this, so I emailed the person "in charge" explaining the problem with accessing the survey. Her Heh, they are ignorants. Anyway, let them come to my http://www.jes.ee/~tonu/c.html page. This page steals clipboard of IE instantly and sends it to my mobile phone plus publishes it on http://no.spam.ee/~tonu/x.html as proof. Anyone is welcome to make own copy, only hidden source code is visible on http://no.spam.ee/~tonu/1.txt I think my mobile gets slashdotted now, need to change number :P Tõnu ___ 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] follow up to SPI Dynamics js portscanner
Hi! I give many classes about security and one major thing about vulnerabilities is difficulty to understand how actually dangerous they are. People often ask "so what" about all the stuff, like this NSA XSS right now. I found useful to develop working demo exploits to make people think bit different. Now again, SPI Dynamics made paper about javascript portscanning and some people implemented nice demos like this one: http://www.gnucitizen.org/projects/javascript-port-scanner/ And again students ask "so what? Nice web frontend to portscanner". So went further and made such web: http://no.spam.ee/scanner/ For people I already shown it was common trend after that visit my pages only with wget and curl :D Tõnu ___ 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] PHP html_decode_entity vulnerability
On Wednesday 29 March 2006 08:51, Tõnu Samuel wrote: > Ok, this "critical" is my fault. Seeing memory dump of other user data There is a one report of this exploit not working. This is vanilla PHP 5.1.2 compiled from source code on Feb 27-th. Tõnu ___ 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] strip_tags() but not only vulnerability
Some time ago I wrote document describing common problem with cleaning up HTML. PHP manual states some little warning about topic but no solution on http://www.php.net/strip_tags Many websites are still vulnerable and similar problems happen not depending on programming language too often: http://www.jes.ee/~tonu/strip.php Please do not start flamewar, I know some people might find this information useful. Yes, it is not "advanced" and this is why people often do not notice the problem. Tõnu ___ 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] Critical PHP bug - act ASAP if you are running web with sensitive data
-- Forwarded Message -- Subject: Re: [Full-disclosure] Critical PHP bug - act ASAP if you are running web with sensitive data Date: Wednesday 29 March 2006 10:06 From: Tõnu Samuel <[EMAIL PROTECTED]> To: Jasper Bryant-Greene <[EMAIL PROTECTED]> On Wednesday 29 March 2006 08:54, you wrote: > Sure, this is still a fairly serious bug. (As an aside, if you have > sensitive data, you really shouldn't allow users to upload new scripts, > or be running in a shared hosting env.) There is a one vector most people do not seem to know. You can telnet to port 80 and say GET I can't speak for other distros, but there's a bug in Gentoo Bugzilla > for this: http://bugs.gentoo.org/127939 Thank you! I think this problem must be fixed in every PHP version, not only 5.1 series. They knew about it but never told. That's bad. Tõnu --- ___ 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] Critical PHP bug - act ASAP if you are running web with sensitive data
Jasper Bryant-Greene wrote: My point is, can you think of a logical reason why html_entity_decode would be run on user input? I'm sure some idiot is doing it (and therefore this is a security issue, though not exactly critical), but I don't think I can think of a reason why it would be done. Why would you want to decode HTML entities given by a user? The opposite (encode their input into HTML entities) is the usual approach... Ok, this "critical" is my fault. Seeing memory dump of other user data seems serious enough to me and I suspected it might affect different functions despite this one. Now when we know more, I agree that it is less critical than suspected by me. Still it is a problem and as subject told: "if you are running web with sensitive data". Malicious user can upload new script and see what others are doing. In most cases not so critical as I assumed but still bad enough and I really expect to see announcements for such problems faster and patches to come out (I mean RPM-s this time). Right now my systems are unprotected till I start to make packages myself or Novell is going to make one. Three weeks is too much. And what about PHP 4.x and 5.0 users? Tõnu ___ 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] Critical PHP bug - act ASAP if you are running web with sensitive data
Slythers Bro wrote: http://127.0.0.1>"; $user = "sqluser"; $pass = "sqlpass"; $foobar=html_entity_decode($_GET['foo']); echo $foobar; ?> Situation is worse. I was able to see 1. Source code itself (may expose bugs in software) 2. Data from other threads. For exaxmple on busy web server I see pieces of HTML other users are seeing. Think if they are watching their private e-mails or use internet banking. What is good for attacker - this exploit does not crash server. Just "reload" and more data is coming. So try it on production server and you see how dangerous it might be. At least till now we got no crashing problems with it. Tõnu ___ 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] Critical PHP bug - act ASAP if you are running web with sensitive data
I very much doubt there are many applications at all containing code like this. It is illogical to be decoding html entities from user input. Therefore I would not call this a "very serious problem" and certainly not a critical bug. Somewhat I agree. I suspected this may affect more functions that only this one and was very alarmed. I never digged around in PHP source and was not able to verify it fast. So if PHP developer says, it is affects only on function, this is fine. There are application which are known to use it. Like http://www.phpmyfaq.de/, so I attacker may use social engineering easily to gain access to such feature. I am security auditor and 90% cases I get to goal combining using bunch of small, useless problems. Sorry if you do not see problem. EOD :). ___ 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] Critical PHP bug - act ASAP if you are running web with sensitive data
Stefan Esser wrote: The bug is a binary safety issue in html_entity_decode. A function that is not usually used on user input, because user input is usually not expected in HTML format and then decoded. Even if the function is used on user input it can only leak memory to a potential attacker if the decoded user input is send back to the client. The bug was found in late February by one of the japanese PHP developers and was fixed in CVS one day later. Because the bug is a local memory leak it was not considered top critical and is among the usual bugfixes. PHP 5.1.3-RC1 which was released in the beginning of March already fixes this issue. Nice! I was really nervous already as I got bombed with e-mails and I really did not knew much more than was discovered. Meanwhile I am bit disappointed that we had nearly month such a bug in wild and software distributors like SuSE in my case did not published patches. I think as long enough time passed and I hope distributors maybe need to see it - I publish exploit. Sorry, this was discovered independently and for me it looks like very serious problem. Script is: Running it with url: http://hostname/index.php?foo=%00 Returns chunk of memory with length equal of string supplied. But instead of k-s you see data like PHP code, PHP ini file, user data, Web pages served to other users and such. There are different PHP applications are vulnerable to this exploit but this is not their fault. Tõnu ___ 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] Critical PHP bug - act ASAP if you are running web with sensitive data
On Tuesday 28 March 2006 15:55, Tõnu Samuel wrote: > Hi everybody! > > I want to tell that pretty nasty bug was discovered in PHP (all tested > versions were vulnerable). I do not want to disclose much details as it may > hurt many websites. I expect PHP team to make patch first. > > There is simple way to protect yourself against this bug if you put some > code in beginning of every source code looking for weird ASCII bytes before > any other code. Make some kind of "white-list" for characters you allow and > deny everything else. I got lot of mails about topic, so I try to make FAQ here. Q: Is it remote or local exploit? A: Both. Works 100% for local and less for remote. Q: Looking weird ascii WHERE? A: in $_GET, $_POST, $_COOKIE and $_REQUEST. This should help in most cases. Q: Why did you posted so few information? A: More seems to be dangerous. I hope this case it is possible to fight problem before real 0day is coming out. Q: Which exact PHP versions are affected? A: I believe ALL of them. I am running 5.0.4 coming with SuSE 10 and all updates but I received reports for other distributions and PHP 4 and 5 both are vulnerable. One more thing - many people mail me from public webmail accounts telling "I am the admin of big bank, can you tell details?". Sorry, I do not know if you are real or not. Tõnu ___ 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] Critical PHP bug - act ASAP if you are running web with sensitive data
Hi everybody! I want to tell that pretty nasty bug was discovered in PHP (all tested versions were vulnerable). I do not want to disclose much details as it may hurt many websites. I expect PHP team to make patch first. There is simple way to protect yourself against this bug if you put some code in beginning of every source code looking for weird ASCII bytes before any other code. Make some kind of "white-list" for characters you allow and deny everything else. More details to come when we have PHP patches distributed with major distributions. I might disclose details before to some IDS vendor or other trusted party. Tõnu ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
