# allow_url_include and php:/data: - Thread: https://externals.io/message/26318 - Original archive: https://news-web.php.net/php.internals/26318 - Started by Stanislav Malyshev on 2006-11-04T09:33:04+00:00 - Messages: 26 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/26318.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #26318 — Stanislav Malyshev — 2006-11-04T09:33:04+00:00 URL: https://externals.io/message/26318#26318 Stefan Esser writes here: http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html that allow_url_include (and allow_url_fopen) can be easily worked around - i.e. extrenally-supplied code executed on server - by using php: and data: URLs. I think if we want allow_url_include have any value than we should fix it... What do you think? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26326 — Rasmus Lerdorf — 2006-11-04T20:40:01+00:00 URL: https://externals.io/message/26318#26326 · In reply to: #26318 Stanislav Malyshev wrote: > Stefan Esser writes here: > http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html > > that allow_url_include (and allow_url_fopen) can be easily worked around > - i.e. extrenally-supplied code executed on server - by using php: and > data: URLs. I think if we want allow_url_include have any value than we > should fix it... What do you think? Yeah, we probably should. Had a chat with Wez about it too. Here is the patch. I think this catches the cases we are interested in: http://lerdorf.com/php/is_url.diff If someone could doublecheck it against those attacks it would be helpful. -Rasmus --- ## #26327 — Peter Brodersen — 2006-11-04T21:12:56+00:00 URL: https://externals.io/message/26318#26327 · In reply to: #26326 On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals rasmus@lerdorf.com (Rasmus Lerdorf) wrote: >Yeah, we probably should. Had a chat with Wez about it too. Here is >the patch. I think this catches the cases we are interested in: > > http://lerdorf.com/php/is_url.diff > >If someone could doublecheck it against those attacks it would be helpful. Would requests to a smbserver, e.g. \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It seems like smbserver requests are regarded as part of the default filesystem wrapper. -- - Peter Brodersen --- ## #26328 — Nuno Lopes — 2006-11-04T22:08:43+00:00 URL: https://externals.io/message/26318#26328 · In reply to: #26318 > Stefan Esser writes here: > http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html > > that allow_url_include (and allow_url_fopen) can be easily worked around - > i.e. extrenally-supplied code executed on server - by using php: and > data: URLs. I think if we want allow_url_include have any value than we > should fix it... What do you think? I don't usually intervene in discussions nor rudenesses here, but this time I felt I had to write this.. I'm pretty tired and reading such pathetic posts is frustrating.. Well in first place I think Stefan should define in which side he is. He pretends to be a PHP developer, but he doesn't act as one, as it posted a message in his blog saying that a product that he supposedly helps to make is insecure.. This is not really ethical, IMHO. If he found some problem (security related or not), the first thing he would have to do was to warn the PHP team (or fix it directly), not to release a public advisory, nor an exploit, nor a slashdot/digg/... post, nor whatever.. But yes, I agree with Ramus' patch. > Would requests to a smbserver, e.g. > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It > seems like smbserver requests are regarded as part of the default > filesystem wrapper. Well, this is a windows only problem. open_basedir will block it, but probably it won't be blocked by anything else as it is handled as a local file by the OS. However, we can/should also think in this problem. Nuno --- ## #26329 — Stefan Esser — 2006-11-04T22:28:31+00:00 URL: https://externals.io/message/26318#26329 · In reply to: #26328 Nuno, there is a simple answer to your email: stick your anti Esser propaganda deep into some place noone is interested in. Before I posted about this, I brought this topic up MONTHS before PHP 5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6 tree. And now please die or just shut the fuck up. I am sick of morons like you who believe they can attack me without knowing the facts. Stefan Esser --- ## #26330 — Nuno Lopes — 2006-11-04T22:58:47+00:00 URL: https://externals.io/message/26318#26330 · In reply to: #26329 > Nuno, > > there is a simple answer to your email: > > stick your anti Esser propaganda deep into some place noone is > interested in. I was already expecting this kind of answer from you, but you clearly don't know me. The previous e-mail wasn't a personal attack nor an attack to your business, nor I was doing any type of propaganda against you. I really appreciate your effort in researching new security problems in PHP itself and in its usage. I personally also like to analyze the PHP code when I have some free time as you do, which is a task that most developers doesn't usually like. > Before I posted about this, I brought this topic up MONTHS before PHP > 5.2 was released. Even before this patch made it into PHP 5.2 from PHP 6 > tree. I didn't know that, really. But in theory I'm also a PHP developer (although not very active) and I didn't receive any information about that. So, I don't know who knew that. But if the security team was aware of that, I present my excuses to you. > And now please die or just shut the fuck up. I am sick of morons like > you who believe they can attack me without knowing the facts. If people doesn't know the facts, just explain the things to them nicely. No violence is needed, IMHO. Nuno --- ## #26335 — Stanislav Malyshev — 2006-11-05T05:51:37+00:00 URL: https://externals.io/message/26318#26335 · In reply to: #26327 > Would requests to a smbserver, e.g. > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It > seems like smbserver requests are regarded as part of the default > filesystem wrapper. Good point. Generally I'd say it belongs to the OS, but I'm not sure if you can restrict this from OS side? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26337 — Stefan Esser — 2006-11-05T07:55:03+00:00 URL: https://externals.io/message/26318#26337 · In reply to: #26330 Hi Nuno, > > I was already expecting this kind of answer from you, but you clearly > don't know me. > The previous e-mail wasn't a personal attack nor an attack to your > business, nor I was doing any type of propaganda against you. Calling my actions unethical and my posts pathetic is kinda a personal attack in the real world. > I didn't know that, really. But in theory I'm also a PHP developer > (although not very active) and I didn't receive any information about > that. > So, I don't know who knew that. But if the security team was aware of > that, I present my excuses to you. The fact that allow_url_fopen does not affect php://input was not only brought up by me before but is actively used by skript kiddies for years. And I really don't like to repeat myself 1000 times. When I brought this up the response I got was: "Yeah whatever. Stopping a few URLs is better than stopping none." > > If people doesn't know the facts, just explain the things to them > nicely. No violence is needed, IMHO. Well PHP developers discuss on IRC how to kill me best by shooting me in my back. I am just answering in the same tone. Stefan --- ## #26342 — Ilia Alshanetsky — 2006-11-05T16:08:05+00:00 URL: https://externals.io/message/26318#26342 · In reply to: #26327 I think it'd be wrong to consider networked file system as non-local. Mostly because many times there are no ways to identify them reliable and the fact this is a perfectly valid usage that if disallowed by default would break a large number of applications. > On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals > rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > > > […] > > > Would requests to a smbserver, e.g. > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It > seems like smbserver requests are regarded as part of the default > filesystem wrapper. > > -- > - Peter Brodersen > > -- > > > > Ilia Alshanetsky --- ## #26343 — Wez Furlong — 2006-11-05T16:13:18+00:00 URL: https://externals.io/message/26318#26343 · In reply to: #26342 I think it's a fair assumption that a random host specified in that way be treated as suspicious and lumped in under the disable-includes-by-default category. If someone discovers that it breaks their app, when they read the docs for allow_url_include it should be made very clear what the implications are and what should be done prior to turning it on. So i have no problem with disallowing includes for paths beginning with a double backslash on windows, when allow_url_include is disabled. --Wez. > I think it'd be wrong to consider networked file system as non-local. > Mostly because many times there are no ways to identify them reliable > and the fact this is a perfectly valid usage that if disallowed by > default would break a large number of applications. > > > > > > […] > > Ilia Alshanetsky --- ## #26346 — Ilia Alshanetsky — 2006-11-05T16:23:03+00:00 URL: https://externals.io/message/26318#26346 · In reply to: #26343 > I think it's a fair assumption that a random host specified in that > way be treated as suspicious and lumped in under the > disable-includes-by-default category. What's random? Non localhost/127.0.0.1 ? > If someone discovers that it breaks their app, when they read the docs > for allow_url_include it should be made very clear what the > implications are and what should be done prior to turning it on. > > So i have no problem with disallowing includes for paths beginning > with a double backslash on windows, when allow_url_include is > disabled. > > --Wez. > > > > > […] > Ilia Alshanetsky --- ## #26347 — Peter Brodersen — 2006-11-05T16:37:53+00:00 URL: https://externals.io/message/26318#26347 · In reply to: #26343 Hi, At first I didn't think there would be an easy solution as it isn't possible to distinguish between requests to a "local" SMB server and an "outside" server. Both are network requests. But on the other hand, requesting a file specific via network protocols in PHP such as SMB or HTTP or FTP really shouldn't be any different. One is asking PHP to perform the network operation to fetch a foreign resource. The key is that administrators would be able to map the needed SMB servers as local devices (just as one would mount a NFS share or for that sake make an FTP mount) thorugh the operating/file system. In that case requesting e.g. Z:\file.txt though a device on a SMB server share (or a NFS share or a FTP share or ...) would be perfectly fine. In that case it would be the operating/file system that is performing the network operation (based on central server administration) and not some random PHP code (possibly based on user input). Of course, those rare cases where one would actually need to fetch files through arbitrary external hosts through PHP one could just turn on allow_url_include. On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com ("Wez Furlong") wrote: >I think it's a fair assumption that a random host specified in that >way be treated as suspicious and lumped in under the >disable-includes-by-default category. > >If someone discovers that it breaks their app, when they read the docs >for allow_url_include it should be made very clear what the >implications are and what should be done prior to turning it on. > >So i have no problem with disallowing includes for paths beginning >with a double backslash on windows, when allow_url_include is >disabled. > >--Wez. > > > > > […] -- - Peter Brodersen --- ## #26348 — Peter Brodersen — 2006-11-05T16:41:39+00:00 URL: https://externals.io/message/26318#26348 · In reply to: #26346 Hi, On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals ilia@prohost.org (Ilia Alshanetsky) wrote: > > […] > >What's random? Non localhost/127.0.0.1 ? Actually any smb server that is requested thorugh PHP's means of fetching a resource (\\smbserver\...) instead of a device mount in the operating system (e.g. Z:\ ...). -- - Peter Brodersen --- ## #26349 — Ilia Alshanetsky — 2006-11-05T17:03:41+00:00 URL: https://externals.io/message/26318#26349 · In reply to: #26348 What's to say /drive/smb or letter:// is not an SMB device? Also why break perfectly valid applications that perform operations on networked file systems? > Hi, > > On Sun, 5 Nov 2006 11:23:03 -0500, in php.internals ilia@prohost.org > (Ilia Alshanetsky) wrote: > > > […] > > Actually any smb server that is requested thorugh PHP's means of > fetching a resource (\\smbserver\...) instead of a device mount in the > operating system (e.g. Z:\ ...). > > -- > - Peter Brodersen > Ilia Alshanetsky --- ## #26351 — Rasmus Lerdorf — 2006-11-05T17:13:36+00:00 URL: https://externals.io/message/26318#26351 · In reply to: #26349 Ilia Alshanetsky wrote: > What's to say /drive/smb or letter:// is not an SMB device? Also why > break perfectly valid applications that perform operations on networked > file systems? We are only talking about marking them as is_url which doesn't have anything to do with performing normal operations on networked filesystems. How many real apps rely on being able to execute code via an smb include? The exact same argument could me made for a localhost http or ftp include which we also disallow. The fact that someone can map a remote machine to a local drive actually means that they can make sure their app works because then they have pre-configured which hosts are valid hosts for this use. If a bad guy can mount remote filesystems onto your server, then you have bigger problems. -Rasmus --- ## #26352 — Ilia Alshanetsky — 2006-11-05T17:22:59+00:00 URL: https://externals.io/message/26318#26352 · In reply to: #26351 > Ilia Alshanetsky wrote: > > […] > > We are only talking about marking them as is_url which doesn't have > anything to do with performing normal operations on networked > filesystems. How many real apps rely on being able to execute code > via > an smb include? Quite a few since many "real apps" will happily install on an SMB share in a linux or windows environment. While this is an uncommon practice on linux I've seen this done many times in the Windows environment. In linux I have seen this date frequently for backup purposes (managed by PHP app) where php would create a backup and write it to the storage machine via SMB. Quite a few big hosters now offer access to SAN via SMB for backup purposes. > The exact same argument could me made for a localhost > http or ftp include which we also disallow. The fact that someone can > map a remote machine to a local drive actually means that they can > make > sure their app works because then they have pre-configured which hosts > are valid hosts for this use. Not all users can mount the smb system due to permission restrictions or simple lack of knowhow on how to do that. While latter can be solved, solving the former is quite a bit trickier. Ilia Alshanetsky --- ## #26357 — Ilia Alshanetsky — 2006-11-05T18:02:24+00:00 URL: https://externals.io/message/26318#26357 · In reply to: #26351 > The exact same argument could me made for a localhost > http or ftp include which we also disallow. For http allowing localhost access is dangerous simply because the person could make the script request itself making a very nasty request loop that will instantly result in a denial of service that requires nothing short of a web server restart to resolve. Ilia Alshanetsky --- ## #26363 — Stanislav Malyshev — 2006-11-05T18:22:12+00:00 URL: https://externals.io/message/26318#26363 · In reply to: #26349 Ilia Alshanetsky wrote: > What's to say /drive/smb or letter:// is not an SMB device? Also why > break perfectly valid applications that perform operations on networked > file systems? Well, it's the same as asking why break valid apps that perform operations on URL. Because of security policy - i.e., if we choose to have security policy that disallows running code with non-local origin influenced by user data - we must do it full nine yards, not "we won't give it to you by http, but you are welcome to do it by smb". Now, if it would be not allowed by default by Windows (AFAIK it is allowed) or there's known way to restrict that from Windows (which I don't know of) - then we may defer this task to the OS, but if there's none, then I don't see how http here would differ from smb... If we say including file from http source is not OK, then why would including file from smb source ok? -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26364 — Rasmus Lerdorf — 2006-11-05T18:25:48+00:00 URL: https://externals.io/message/26318#26364 · In reply to: #26357 Ilia Alshanetsky wrote: > > > > […] > > For http allowing localhost access is dangerous simply because the > person could make the script request itself making a very nasty request > loop that will instantly result in a denial of service that requires > nothing short of a web server restart to resolve. I still think disallowing anything that in any way looks like it could be a remote include, even if under the covers it isn't, is what we should be doing here when allow_url_include is disabled. The chance of false positives doesn't change anything. -Rasmus --- ## #26367 — Ilia Alshanetsky — 2006-11-05T18:51:29+00:00 URL: https://externals.io/message/26318#26367 · In reply to: #26363 > Ilia Alshanetsky wrote: > > […] > > Well, it's the same as asking why break valid apps that perform > operations on URL. I guess it is a question of frequency, as a rule a valid use of require/include on a URL is quite unusual. From my experience, I do not believe the same could be said about smb. > Because of security policy - i.e., if we choose to have security > policy that disallows running code with non-local origin influenced > by user data - we must do it full nine yards, not "we won't give it > to you by http, but you are welcome to do it by smb". This is a valid point, but at the same time we need to consider the consequences marking of smb:// as url will have on PHP applications and weather this is something to be done in a patch level release. Exploitation wise all of the hacks I've seen for remote code execution were based on http as that provides the best degree of anonymity for a hacker, a freehosting page somewhere sending php code via text file. Use of SMB requires a more tricky infrastructure in a form of an open smb share, usually meaning an exploited win32 box that accepts incoming smb connections. > Now, if it would be not allowed by default by Windows (AFAIK it is > allowed) or there's known way to restrict that from Windows (which > I don't know of) - then we may defer this task to the OS, but if > there's none, then I don't see how http here would differ from > smb... If we say including file from http source is not OK, then > why would including file from smb source ok? A firewall rule can be used to block outgoing smb connections quite easily on both linux and windows. Ilia Alshanetsky --- ## #26373 — Stanislav Malyshev — 2006-11-06T03:19:09+00:00 URL: https://externals.io/message/26318#26373 · In reply to: #26367 > I guess it is a question of frequency, as a rule a valid use of > require/include on a URL is quite unusual. From my experience, I do not > believe the same could be said about smb. How many apps really need to import includes from foreighn systems which aren't mounted as drive letters? I don't think anybody does (or should) build an applications like that. > This is a valid point, but at the same time we need to consider the > consequences marking of smb:// as url will have on PHP applications and > weather this is something to be done in a patch level release. Sure, we need to consider that - I think that's exactly what we are doing now :) My assessment would be people usually don't do that purposefully, but you and everybody on the list are welcome to give examples to the contrary of course. > Exploitation wise all of the hacks I've seen for remote code execution > were based on http as that provides the best degree of anonymity for a SMB can be as anonymous as HTTP. The reason why HTTP is used more because you can easily buy HTTP hosting solution and SMB hosting would probably cost more, and because HTTP is much more known and easy to set up right to the script kiddies of all kinds. But once people figure out something can be hacked through SMB means, they would write a script to do it and script kiddies would do it as easily as anything. Once writing an exploit was are that few could master, now there are ready-made rootkits for any vulerability out there for anybody to use. > Use of SMB requires a more tricky infrastructure in a form of an open > smb share, usually meaning an exploited win32 box that accepts incoming > smb connections. "Pwned" windows boxes are not unheard of, to say the least. :) And any unix can do smb as good as windows, thanks to samba team ;) > A firewall rule can be used to block outgoing smb connections quite > easily on both linux and windows. Yes, sure - though standard config does not block that AFAIK and the whole point of allow_url_include is to protect such configs as far as I understand. -- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ --- ## #26380 — Richard Quadling — 2006-11-06T08:55:05+00:00 URL: https://externals.io/message/26318#26380 · In reply to: #26347 I develop solely on and for our Windows network. I regularly use includes on 2 different servers via \\ rather than a mapped drive. I can see that adding \\ to the list of restrictions would be an issue for me. But also, it is a trivial ini update to remove the problem. And it DOES make PHP more secure. So, +1 to add \\ to the list of restrictions. Not so sure it would be as easy for shared host ISPs on Windows to fix this though. > Hi, > > At first I didn't think there would be an easy solution as it isn't > possible to distinguish between requests to a "local" SMB server and > an "outside" server. Both are network requests. > > But on the other hand, requesting a file specific via network > protocols in PHP such as SMB or HTTP or FTP really shouldn't be any > different. One is asking PHP to perform the network operation to fetch > a foreign resource. > > The key is that administrators would be able to map the needed SMB > servers as local devices (just as one would mount a NFS share or for > that sake make an FTP mount) thorugh the operating/file system. > > In that case requesting e.g. Z:\file.txt though a device on a SMB > server share (or a NFS share or a FTP share or ...) would be perfectly > fine. In that case it would be the operating/file system that is > performing the network operation (based on central server > administration) and not some random PHP code (possibly based on user > input). > > Of course, those rare cases where one would actually need to fetch > files through arbitrary external hosts through PHP one could just turn > on allow_url_include. > > On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com > ("Wez Furlong") wrote: > > > […] > > -- > - Peter Brodersen > > -- > > > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #26381 — Tom Sommer — 2006-11-06T12:23:12+00:00 URL: https://externals.io/message/26318#26381 · In reply to: #26380 > I develop solely on and for our Windows network. I regularly use > includes on 2 different servers via \\ rather than a mapped drive. > > I can see that adding \\ to the list of restrictions would be an issue > for me. > > But also, it is a trivial ini update to remove the problem. And it > DOES make PHP more secure. > > > So, +1 to add \\ to the list of restrictions. > > > Not so sure it would be as easy for shared host ISPs on Windows to fix > this though. This seems to be more of a network setup issue, rather than a PHP issue. If you haven't blocked access to remote SMB servers in your network, you are asking for trouble. If you have a rogue SMB box or mount on your network, PHP is the least of your problems. You can pretty much guarantee that if people are including URLs, they are either asking for trouble or looking for it. Blocking network mounts seems to be too much of an edge case for it to be included as a feature in allow_url_include, as it might have valid uses while URLs does not. You could add a allow_remote_include option, but that would require another INI option, and those aren't so popular :) My two cents // Tom --- ## #26384 — Ilia Alshanetsky — 2006-11-06T16:25:18+00:00 URL: https://externals.io/message/26318#26384 · In reply to: #26373 Well, it looks like the overall consensus is that we add this restriction, so let's add in it. It seems I am the only one somewhat against it... > > […] > > How many apps really need to import includes from foreighn systems > which aren't mounted as drive letters? I don't think anybody does > (or should) build an applications like that. > > > […] > > Sure, we need to consider that - I think that's exactly what we are > doing now :) My assessment would be people usually don't do that > purposefully, but you and everybody on the list are welcome to give > examples to the contrary of course. > > > […] > > SMB can be as anonymous as HTTP. The reason why HTTP is used more > because you can easily buy HTTP hosting solution and SMB hosting > would probably cost more, and because HTTP is much more known and > easy to set up right to the script kiddies of all kinds. But once > people figure out something can be hacked through SMB means, they > would write a script to do it and script kiddies would do it as > easily as anything. Once writing an exploit was are that few could > master, now there are ready-made rootkits for any vulerability out > there for anybody to use. > > > […] > > "Pwned" windows boxes are not unheard of, to say the least. :) And > any unix can do smb as good as windows, thanks to samba team ;) > > > […] > > Yes, sure - though standard config does not block that AFAIK and > the whole point of allow_url_include is to protect such configs as > far as I understand. > > -- > Stanislav Malyshev, Zend Products Engineer > stas@zend.com http://www.zend.com/ > > -- > > > > Ilia Alshanetsky --- ## #26385 — Richard Lynch — 2006-11-06T18:46:15+00:00 URL: https://externals.io/message/26318#26385 · In reply to: #26351 > Ilia Alshanetsky wrote: > > […] > > We are only talking about marking them as is_url which doesn't have > anything to do with performing normal operations on networked > filesystems. How many real apps rely on being able to execute code > via > an smb include? The exact same argument could me made for a localhost > http or ftp include which we also disallow. The fact that someone can > map a remote machine to a local drive actually means that they can > make > sure their app works because then they have pre-configured which hosts > are valid hosts for this use. If a bad guy can mount remote > filesystems > onto your server, then you have bigger problems. Maybe I'm just being stupid (again) but it seems like all of this is kinda pointless... I mean, if you're dumb enough to include() source code from some random computer you don't control/trust, what do you really expect as the outcome? I realize that a lot of idiots did: include $path; with register_globals on as part of their code, and allow_url_include is trying to stem the tide of disasters that caused... But, really, can somebody be both smart enough to get SMB to even work, then manage to mount somebody else's untrusted drive or be dumb enough to let somebody else mount their own SMB drive, and then include() it i their PHP code? How likely is this scenario? And how many Real Uses are going to be impacted by dis-allowing SMB shares? Does anybody *need* this feature? Somebody posted that large ISPs are using SMB shares -- Perhaps asking them if this would kill them, or if they could manage to mount everything as a named drive. They're probably the ones most at-risk and with the best understanding of the Real World issues/risks. It's entirely possible, yea, even likely, that I'm "missing" something fundamental here, but it seems like you're trying to block something that only somebody really smart could intentionally open up to "prove" how insecure PHP is, rather than an actual Security Issue. PS I found it interesting that the CAPTCHA on the blog that started this thread doesn't work... And the comments box doesn't scroll properly when you type too much. [Which I'm sure some here think I type too much anyway... ;-)] PPS Since I will most likely never be responsible for an SMB share as a repository for source code in a production environment, I don't have a personal stake in this one, as interesting as it as an academic exercise in "Security". :-) +0.00001 -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --- Next page: https://externals.io/message/26318.md?page=2