Jade, It is a security issue mostly because the code sequence is incorrect. (which also means that ns_returnfile should not be used for temp file return)
The safe way to do this is to open the temp file, then immediately unlink it! Then write to the fd. BTW, this same bug exists in the ns_form/ns_conn files code which should use fd's instead of files. We need a little code cleanup here. tom jackson On Mon, 2008-08-18 at 15:30 -0700, Jade Rubick wrote: > I would call that a security issue then. Leaking the wrong data to the > wrong connection is pretty serious. > > Jade > > Jade Rubick > Director of Development > Truist > 120 Wall Street, 4th Floor > New York, NY USA > [EMAIL PROTECTED] > +1 503 285 4963 > +1 707 671 1333 fax > > > > The information contained in this email/document is confidential and > may be legally privileged. Access to this mail/document by anyone > other than the intended recipient(s) is unauthorized. If you are not > an intended recipient, any disclosure, copying, distribution, or any > action taken or omitted to be taken in reliance to it, is prohibited. > > > On Mon, Aug 18, 2008 at 2:13 PM, John Caruso > <[EMAIL PROTECTED]> wrote: > On Monday 01:33 PM 8/18/2008, Tom Jackson wrote: > It's not be a data corruption issue > because you are choosing to overwrite the old data > with new data using > the exact same file name. If the data is important, > don't overwrite it, > thus no corruption. > > > No, you've misunderstood the scenario. The file name needn't > be the same to trigger this issue, and the "corruption" > doesn't come from serving data out of a file that's changing, > but rather because fastpath caching mistakenly identifies a > new file as being identical to a previously-cached file (for > the reasons I outlined) and erroneously serves the > previously-cached data to the user. > > This is a design limitation and arguably a bug in the fastpath > caching implementation, which is potentially quite serious > since it silently serves the wrong data to the user. If you > want a more straightforward (albeit contrived) demonstration > of the problem, here you go: > > set file [open "/var/tmp/myfile" "w"] > puts $file "ABC123" > close $file > ns_returnfile 200 text/plain "/var/tmp/myfile" > ns_unlink -nocomplain "/var/tmp/myfile" > > set file [open "/var/tmp/myotherfile" "w"] > puts $file "XYZ987" > close $file > ns_returnfile 200 text/plain "/var/tmp/myotherfile" > ns_unlink -nocomplain "/var/tmp/myotherfile" > > Assuming that /var/tmp/myfile and /var/tmp/myotherfile are > created within the same second, the fastpath caching algorithm > will misidentify them as the same file, and ns_returnfile will > therefore erroneously return the (previously cached) contents > of /var/tmp/myfile when it should be returning the (uncached) > contents of /var/tmp/myotherfile. > > > > - John > > > -- > AOLserver - http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[EMAIL PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can > leave the Subject: field of your email blank. > > > > > -- > AOLserver - http://www.aolserver.com/ > > > > To Remove yourself from this list, simply send an email to <[EMAIL > PROTECTED]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: > field of your email blank. > > -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
