lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <0002eacfdbfa9afc43034758e0a68b0f@mail.ankalagon.ru> Date: Fri, 21 Jan 2011 20:02:31 +0300 From: Владимир Воронцов <vladimir.vorontsov@...ec.ru> To: ascii <ascii@...amail.com>, Full disclosure <full-disclosure@...ts.grok.org.uk> Subject: Re: Oddities of PHP file access in Windows ®. Cheat-sheet [maybe 0day] Dear ascii! We do not really read your article, it happens - no one can read all the information available online. I apologize, really, in this work repeats much your work. I learned about your paper later from thewildcat (twitter): Wildcat @@ d0znpp @ 0x6D6172696F nice paper:), the ush.it php-filesystem-attack articles from 2009 are also very good http://pastebin.com/TwvfQeK6 Of course, we'll add a link to your work in article. Thank you for your fair criticism! > http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/ > http://www.ush.it/2009/07/26/php-filesystem-attack-vectors-take-two/ Also, in your work, I could not find explanations of strange behavior of characters < > " in the filename. And also could not find mention of functions other than include, require (_once). I express once again my apologies. On Fri, 21 Jan 2011 17:19:54 +0100, ascii <ascii@...amail.com> wrote: > On 01/12/2011 09:59 AM, [UNICODE] wrote: >> And we never can know what nifty tricks PHP >> interpreter had reserved for our next >> day. In this paper we will describe details about how PHP treats file >> names on Windows operating >> systems, regarding the presence of different fuzzy characters >> >> Original English article: http://onsec.ru/onsec.whitepaper-02.eng.pdf > > Dear ONSEC, > > I don't know what name you are willing do to of your company by > publishing such papers. To me it seems important to behave in a correct > way by citing prior works. Rehashing and ripping seems a dismal choice. > > It seems really hard to believe that you failed to stumble upon our > papers during your "research". > > http://www.ush.it/2009/02/08/php-filesystem-attack-vectors/ > http://www.ush.it/2009/07/26/php-filesystem-attack-vectors-take-two/ > > But let's analyze the paper, page by page, and try to understand the > amount of "original" work here. > > - Page 1 > > Vladimir Vorontsov (d0znpp@...ec.ru / https://twitter.com/#!/d0znpp), > Arthur Gerkis (arthur.gerkis@...ec.ru / https://twitter.com/#!/ax330d). > ONsec - security research team (http://onsec.ru). > Greetz to RDOT (http://rdot.org) > > What we learn from this page? > > That the two "researchers", "d0znpp" and "ax330d", are the lax > "authors" of the research. > > - Page 2 > > Nothing interesting. Fuffa. > > - Page 3 > > Nothing interesting. Menu. > > - Page 4 > > Ripped information, copy and paste. Prologue. > > What we learn from this page? > > The two researchers didn't known of this technique, found a Chinese > document explaining some code auditing tips for PHP code. Amazed the > two decided to completely rip the code and rephrase the results. > > Translation of the .ch text is: "We are in the windows system running > the above code are the following characters * <>? P p can open the > directory 1.php." > > The promise of the paper authors is that the "Current paper will show > the results of further investigation of such weird behavior.". > > In our opinion great parts of their further investigations is already > contained in our paper, from 2009. > > - Page 5 > > "Investigating our fuzzing results" > > Moreover, during the trace of call stack it was found out that the > character > gets replaced with ?, character < transforms to *, and " > (double quote) is replaced by a . (dot). This bug has already been > described in MSDN in 2007 year: http://msdn.microsoft.com/en- > us/library/community/history/aa364418(v=vs.85).aspx?id=3. > > The point is, this is uber well known well before 2007. > > Our paper was writing: > > - On Windows OS both (include|require)(_once)? functions will convert > "foo.php" followed by one or more of the chars \x20 ( ), \x22 ("), > \x2E (.), \x3C (<), \x3E (>) back to "foo.php". > > We were not aware of the MS document, but in general we are always > happy to cite and link to previous works. So my opinion is that if we > stumbled upon that document at the time of our research it would be > surely included. > > http://msdn.microsoft.com/en-us/library/aa364418%28v=vs.85%29.aspx > > - Page 6 > > Perhaps the first useful bit of the paper. An investigation of witch > functions use FindFirstFile() internally. > > - Page 7 and 8 > > Nothing interesting. If you take a closer look the code is taken from > http://msdn.microsoft.com/en-us/library/aa364418%28v=vs.85%29.aspx > > No idea why they republished it. > > - Page 9 > > "Collecting together all the known tricks to access files in Windows" > > Yeah, the point is that these trick have not been discovered by ONSEC > authors! The issue is that ONSEC's researchers totally fail to > understand this and even write the following sentence: > > "During our research we have tested different combinations of file > names and functions, that resulted into the following cheat-sheet." > > Tip 1: Known. 100% shown in our paper. > Tip 2: Known. Documented by MS. 90% already shown in our paper. > Tip 3: Known. Documented by MS. 90% already shown in our paper. In > addition we show that the dot at the end of the filename is ignored. > Tip 4: Known. Documented by MS. 90% already shown in our paper. > Tip 5: Known. 100% already shown in our paper. > Tip 6: "This is obvious and was known for a long time." > [etc..] > > Summarizing our feeling is that ONSEC published a paper that mostly > rehash the contents of a paper* that is a rehash of research published > by others, incorrectly citing (or better, not citing at all) previous > works and sources and essentially unfairly taking credits. > > The value of the spots of actual research that are contained in the > paper is ruined by this. > > Regards, > Francesco `ascii` Ongaro > > * As shown by the dates in http://code.google.com/p/pasc2at/updates/list -- Best regards, Vladimir Vorontsov ONsec security expert _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists