[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] 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@xxxxxxxxxxxx> 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@xxxxxxxx / https://twitter.com/#!/d0znpp),
> Arthur Gerkis (arthur.gerkis@xxxxxxxx / 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/