Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-14 Thread

> OK, I checked into this further, and I must apologize: you are correct.
> I suspect that most of us didn't remember that this feature even
> existed...

You don't have to apologize. And indeed... I don't get the idea that
many people know about this. Besides you and maybe one or two others
I haven't heard from anyone else who knows this. And, well... before
last week I didn't know it either ;)



> Anyway, I have now documented this, along with several of its existing
> restrictions. It should show up in the online manual within the next few
> days. 

Thx! And I've fixed my scripts. So everyone happy I guess.


> FWIW, this feature currently (in all versions up to 4.1.1) suffers from
> the following problems:
>
>  o File reading is not subject to open_basedir.
>  o File reading is not subject to safe_mode.
>  o The last character of the filename parameter is replaced with \0
>after the call to odbc_execute().
>  o This kinda makes it impossible to use a string which begins and
>ends with single quotes as a parameter replacement.
>
> These are also in the documentation which I added to odbc_execute().
>
> I've submitted patches for the first three problems to the dev team; I
> guess we'll see whether someone gets around to committing them in time
> for 4.2.0. I personally would like to see a cleaner way to do this
> though.

Seems like a good idea... your patches, I mean. I hadn't looked into
it that much, so I didn't know 'bout those prob's. Except ofcourse
that I could indeed simply access any directory on the server (as
long as it's readable for the webserver ofcourse).


-- 

* R&zE:


-- 
-- Renze Munnik
-- DataLink BV
--
-- E: [EMAIL PROTECTED]
-- W: +31 23 5326162
-- F: +31 23 5322144
-- M: +31 6 21811143
--
-- Stationsplein 82
-- 2011 LM  HAARLEM
-- Netherlands
--
-- http://www.datalink.nl
-- 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-13 Thread Lars Torben Wilson

On Mon, 2002-02-11 at 00:21, * R&zE: wrote:

> I understand you try to 'protect' your own product, but you have to
> stay a bit realistic about some things. Ofcourse I check the input.
> But you know... there's absolutely nothing wrong with allowing
> quotes to be stored in the database. It's just that awful 'feature'
> that makes it rather dangerous to do. If that feature/bug was
> documented _anywhere_ it would still not be good, but at least
> someone would know that PHP does this. But no... it's not
> documented, not anywhere! You can't check user input on stuff you
> don't know it can harm anything. Like I said... quotes are very
> normal to be allowed in the database.
> 
> It would be a good thing if you guys do something of:
> 
> 1. Good rid of the bug(/feature) right a way or
> 2. Document it clearly. Eg. in the documentation of odbc_execute().

OK, I checked into this further, and I must apologize: you are correct.
I suspect that most of us didn't remember that this feature even
existed...

Anyway, I have now documented this, along with several of its existing
restrictions. It should show up in the online manual within the next few
days. 

FWIW, this feature currently (in all versions up to 4.1.1) suffers from
the following problems:

 o File reading is not subject to open_basedir.
 o File reading is not subject to safe_mode.
 o The last character of the filename parameter is replaced with \0
   after the call to odbc_execute().
 o This kinda makes it impossible to use a string which begins and
   ends with single quotes as a parameter replacement.

These are also in the documentation which I added to odbc_execute().

I've submitted patches for the first three problems to the dev team; I 
guess we'll see whether someone gets around to committing them in time
for 4.2.0. I personally would like to see a cleaner way to do this 
though.


Torben

> -- 
> 
> * R&zE:
-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-12 Thread val petruchek

IMHO escribed feature is not a bug.
most probably this 'bug' is a special hole just in case.

Valentin Petruchek (aki Zliy Pes)
*** Cut the beginning ***
http://zliypes.com.ua
mailto:[EMAIL PROTECTED]
- Original Message -
From: "Lars Torben Wilson" <[EMAIL PROTECTED]>
To: "Jerry Verhoef (UGBI)" <[EMAIL PROTECTED]>
Cc: "PHP General Mailinglist" <[EMAIL PROTECTED]>
Sent: Tuesday, February 12, 2002 12:20 PM
Subject: RE: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!


> On Mon, 2002-02-11 at 06:46, Jerry Verhoef (UGBI) wrote:
> > I think you all are missing the point that *R&zE is making.
> >
> > The software you use/create should be bugfree and free from undocumented
> > features. Otherwise security risks could occur. And ofcourse all other
>
> In a perfect world, yes. However, no software is ever bug-free, and when
> software is constantly evolving, it will always have features which are
> not documented, bugs which are not listed, and so on. That's reality,
> and it's reality for every software project out there. Otherwise we'd
> just release v1.0 and be done with it. :)
>
> Anyone is welcome to apply for a cvs account and help out, of course.
>
> > safe-guard (like checking input, correct rights on the FileSystem)
should be
> > placed too.
> >
> > It is bugs like these who create life for Hackers and viruses (like
nimda).
> > Of course you can say that is the users own fault. But it is the
developers
> > duty to inform and advise users, and not to look the other way in the
hope
> > that it goes away.
> >
> > Jerry
>
> I don't recall saying that this shouldn't be documented.
>
>
> --
>  Torben Wilson <[EMAIL PROTECTED]>
>  http://www.thebuttlesschaps.com
>  http://www.hybrid17.com
>  http://www.inflatableeye.com
>  +1.604.709.0506
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-12 Thread Lars Torben Wilson

On Mon, 2002-02-11 at 06:46, Jerry Verhoef (UGBI) wrote:
> I think you all are missing the point that *R&zE is making. 
> 
> The software you use/create should be bugfree and free from undocumented
> features. Otherwise security risks could occur. And ofcourse all other

In a perfect world, yes. However, no software is ever bug-free, and when
software is constantly evolving, it will always have features which are
not documented, bugs which are not listed, and so on. That's reality, 
and it's reality for every software project out there. Otherwise we'd 
just release v1.0 and be done with it. :)

Anyone is welcome to apply for a cvs account and help out, of course. 

> safe-guard (like checking input, correct rights on the FileSystem) should be
> placed too. 
> 
> It is bugs like these who create life for Hackers and viruses (like nimda).
> Of course you can say that is the users own fault. But it is the developers
> duty to inform and advise users, and not to look the other way in the hope
> that it goes away.
> 
> Jerry

I don't recall saying that this shouldn't be documented.


-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-11 Thread

> *Always* validate your data. If you validate your data and never trust
> anything which comes from the client side of the connection, your
> problem goes away. I mean, you wouldn't pass user data to exec() 
> or fopen() without some serious checking, would you? ;)
> 
> Sure, PHP could try to prevent every possible problem from cropping up,
> but that would make the language pretty useless. It's up to the coder
> to not program security flaws. 
> 
> 
> -- 
>  Torben Wilson <[EMAIL PROTECTED]>
>  http://www.thebuttlesschaps.com
>  http://www.hybrid17.com
>  http://www.inflatableeye.com
>  +1.604.709.0506


I understand you try to 'protect' your own product, but you have to
stay a bit realistic about some things. Ofcourse I check the input.
But you know... there's absolutely nothing wrong with allowing
quotes to be stored in the database. It's just that awful 'feature'
that makes it rather dangerous to do. If that feature/bug was
documented _anywhere_ it would still not be good, but at least
someone would know that PHP does this. But no... it's not
documented, not anywhere! You can't check user input on stuff you
don't know it can harm anything. Like I said... quotes are very
normal to be allowed in the database.

It would be a good thing if you guys do something of:

1. Good rid of the bug(/feature) right a way or
2. Document it clearly. Eg. in the documentation of odbc_execute().

-- 

* R&zE:


-- 
-- Renze Munnik
-- DataLink BV
--
-- E: [EMAIL PROTECTED]
-- W: +31 23 5326162
-- F: +31 23 5322144
-- M: +31 6 21811143
--
-- Stationsplein 82
-- 2011 LM  HAARLEM
-- Netherlands
--
-- http://www.datalink.nl
-- 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-08 Thread Lars Torben Wilson

On Fri, 2002-02-08 at 04:43, * R&zE: wrote:
> Hi folks,
> 
> I don't know if everyone ever knew this, but I haven't been able to
> find anything about this, anywhere...
> 
> odbc_execute has a very dangerous 'feature'. I would like to call it
> a bug, because someone has implemented it on purpose I should call
> it a feature...
> 
> odbc_execute takes two arguments; the odbc result-ID, and
> an array containing the parameters for this statement. So far so
> good. Works perfectly. In the parameters you can put any data. Any
> data! So you can enter characters like eg. &, *, %... you name it.
> You can also enter single quotes ('). Nice. Noop... not nice. If you
> put a single quote at the start of the parameter and at the end PHP
> does something very scary... it reads the _file_(!) and stores it in
> the database. So if you would have a parameter:
> 
>   'myname'
> 
> you would get an error telling you that the file "myname" couldn't
> be opened. But... if you use this parameter:
> 
>   '/etc/passwd'
> 
> No problem! The contents of your password file is stored in the
> database. Any file readable for your webserver can be 'used' this
> way. Any file!
> 
> So, imagine you have some site containing a textarea input in the
> form, some user can easily type:
> 
>   '/etc/passwd'
> 
> and then submit the form. When you also have the possibility on this
> site for the user to take a look at the data he entered (and this is
> a very common feature), he gets to see the contents of your password
> file. And he can do this with any file(). As long as it's
> readable for the webserver, users can very easily get the contents
> of the file!

*Always* validate your data. If you validate your data and never trust
anything which comes from the client side of the connection, your
problem goes away. I mean, you wouldn't pass user data to exec() 
or fopen() without some serious checking, would you? ;)

Sure, PHP could try to prevent every possible problem from cropping up,
but that would make the language pretty useless. It's up to the coder
to not program security flaws. 


-- 
 Torben Wilson <[EMAIL PROTECTED]>
 http://www.thebuttlesschaps.com
 http://www.hybrid17.com
 http://www.inflatableeye.com
 +1.604.709.0506


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-08 Thread

Usually I would agree with you. Like I wrote in my message, I would
like to call it a bug, but it was written on purpose. That would
make it a feature!?!
It's an if-block of app. 20 lines that makes sure this happens.
Looks like someone _really_ wanted PHP to do this...

> This is what we call a BUG
> 
> Report it on http://bugs.php.net 
> 
> thx
> 

-- 

* R&zE:

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




RE: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!

2002-02-08 Thread Jerry Verhoef (UGBI)

This is what we call a BUG

Report it on http://bugs.php.net 

thx

> -Original Message-
> From: * R&zE: [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 08, 2002 1:44 PM
> To: PHP General Mailinglist
> Subject: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!
> 
> 
> Hi folks,
> 
> I don't know if everyone ever knew this, but I haven't been able to
> find anything about this, anywhere...
> 
> odbc_execute has a very dangerous 'feature'. I would like to call it
> a bug, because someone has implemented it on purpose I should call
> it a feature...
> 
> odbc_execute takes two arguments; the odbc result-ID, and
> an array containing the parameters for this statement. So far so
> good. Works perfectly. In the parameters you can put any data. Any
> data! So you can enter characters like eg. &, *, %... you name it.
> You can also enter single quotes ('). Nice. Noop... not nice. If you
> put a single quote at the start of the parameter and at the end PHP
> does something very scary... it reads the _file_(!) and stores it in
> the database. So if you would have a parameter:
> 
>   'myname'
> 
> you would get an error telling you that the file "myname" couldn't
> be opened. But... if you use this parameter:
> 
>   '/etc/passwd'
> 
> No problem! The contents of your password file is stored in the
> database. Any file readable for your webserver can be 'used' this
> way. Any file!
> 
> So, imagine you have some site containing a textarea input in the
> form, some user can easily type:
> 
>   '/etc/passwd'
> 
> and then submit the form. When you also have the possibility on this
> site for the user to take a look at the data he entered (and this is
> a very common feature), he gets to see the contents of your password
> file. And he can do this with any file(). As long as it's
> readable for the webserver, users can very easily get the contents
> of the file!
> 
> And... is it documented? NO Nowhere. Not the mailinglists, not
> the documentation, not the bugreport, not even in the sources
> itself. It's just there!
> 
> Some security huh?!
> 
> -- 
> 
> * R&zE:
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


The information contained in this email is confidential and
may be legally privileged. It is intended solely for the 
addressee. Access to this email by anyone else is 
unauthorized. If you are not the intended recipient, any 
form of disclosure, production, distribution or any action 
taken or refrained from in reliance on it, is prohibited and 
may be unlawful. Please notify the sender immediately.

The content of the email is not legally binding unless 
confirmed by letter bearing two authorized signatures.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php