Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!
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). -- * RzE: -- -- 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'!!!
On Mon, 2002-02-11 at 00:21, * RzE: 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 -- * RzE: -- 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'!!!
On Mon, 2002-02-11 at 06:46, Jerry Verhoef (UGBI) wrote: I think you all are missing the point that *RzE 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'!!!
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 *RzE 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'!!!
*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(). -- * RzE: -- -- 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
[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?!
--
* RzE:
--
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'!!!
This is what we call a BUG
Report it on http://bugs.php.net
thx
-Original Message-
From: * RzE: [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?!
--
* RzE:
--
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
Re: [PHP] ODBC_EXECUTE has a DANGEROUS 'feature'!!!
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 -- * RzE: -- 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'!!!
On Fri, 2002-02-08 at 04:43, * RzE: 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
