[PLUG] Preventing Probes Like This

[Tim]

> As an argument, an include/import command that *doesn't*, oh, eval the 
> code that was just imported seems totally silly, as I really don't see 
> what would make sense about a C, PHP, (whatever) program having to 
> include hundreds of header files, and than *also* having to eval those 
> files in another, separate, step. I'm already including the code for 
> pete's sake, why the heck should I have to first include *and* then eval it?
> 
> #include stdio.c
> #eval stdio.c
> ?
> 
> It just seems absurd and nonsensical to me. If all somebody wanted to do 
> in PHP was dump a file into output, fpassthru() does the trick, but 
> forcing all includes/imports (or even just ones with specific contexts?) 
> to run a separate, additional, step, just to acknowledge that the 
> requested imported code/file is, indeed, *requested imported 
> code/files*.... would seem to be a rather astonishing behavior.
> 
> Consider, for a second, the following meta-code, with the "convenience" 
> of eval() added for giggles:
> 
> function SuperKewlLoader ($user_submitted_data_argument){
>     $temp_blob = import ($user_submitted_data_argument);
>     eval ($temp_blob);
> }
> 
> I would argue that the underlying code problem under discussion *isn't* 
> that the PHP import command is doing the wrong thing by, well, importing 
> and evaluating code.

My argument isn't that an imported file shouldn't be eval()ed.  My
argument is that a language macro should be able to include files from
remote systems over protocols like HTTP.  Even without the security
implications, this is a huge hack for a language to have to implement an
HTTP client just to include a file as code.  The fact that PHP has this
behavior is a big surprise to many programmers.  A rather nasty surprise
that results in immediate compromise if you want to have dynamically
included files at all.


> The way I see it, it really doesn't matter if the file is coming from a 
> "bad user's" file on a local physical hard disk, a bad user file hosted 
> via NFS or otherwise on on a SAN, or a bad user file fetched from 
> halfway around the world via http/ftp/vpn 
> tunnel/snail-mail/pigeons/whatever, the problem is that dirty 
> user-submitted data is *intentionally* being allowed to control what 
> code is being imported and executed. The argument could be a local disk 
> file://home/eviluser/badness.php, a remote 
> http://www.example.com/baduser.php, an uploaded /tmp/badness.php, a 
> courier pigeon://african/swallow/badness.php, whatever.
> 
> As soon as a given software author decided that remote end-users could 
> be allowed to submit their own arguments about what files/code were 
> being imported and executed, the game was over. It doesn't matter if the 
> underlying language is PHP, C, Java, Python, it's all the same result. 
> Some languages and platforms may make it *harder* to do such a 
> boneheaded thing ("I see you are trying to let the world access and 
> execute any file on your disk, Cancel or Allow?"), but the fault there 
> isn't really the language, it's with the user who clicks "Allow", or in 
> this discussion, the programmer who *added* that (rather questionable) 
> publicly available feature to their software.


Ok, so here's a separate issue.  I don't disagree with your assertion
that it's a bad idea to allow an untrusted user to specify which files
are included as code.  This is obviously a dangerous thing.  However,
software needs to *fail gracefully*.

Let me say this again: Secure software *fails gracefully*.  The fact
that PHP includes a remote file import macro causes many minor
vulnerabilities to develop into very severe ones.  The typical public
website doesn't allow one to upload files.  This makes it very difficult
to execute code even if you can specify the file to load.

Since most languages don't have this inane feature like PHP does,
programmers aren't used to having to be so careful about injections into
these macros.  This is a big surprise and violates the premise I
mentioned previously.

Sure, if you're a l33t programmer, and you care about writing secure
code, it doesn't matter since you'd just avoid this and other issues.
Unfortunately those are two huge assumptions, the original poster (not
to mention every other PHP app on sourceforge) have clearly
demonstrated.

tim


PS- I think I'm done with this thread.  I don't think I'll convince
    anyone of my views who haven't been convinced already.