Hmm... this is really weird...

Can someone explain this? I look at properties of a file and get
Created : 12 May 2004, 13:17:22
Modified : 27 April 2004, 13:11:22
Accessed: 19 May 2004 20:08:23

How is this possible that a file is modified before it is created? Which date should i trust for last modified date?

Thanks,
crUs

this happens mostly when file extracted (from archive or installer)
(time from archive seems copied to "modified" attr)

if it really bothers you, you can use a tool like this to change the days/times: http://www.eluent.com/eltouch.htm ("http://www.eluent.com/eltouch.htm")

hi disavowed... it doesnt really bother me... i just need to find out the exact time that a file was last modified...

The modified date is gospel, it usually is the actual correct date of when the file was "created", unless the installer was told to set the date to the date of install, in which case, you lose all date info.

-nt20

Is there a difference between file security on Nt/Xp/2k and 9x/me? Or can you still just set the file-times as you wish? Wouldn't be surprised, anyway.

Fake

NTFS has more date info for files than FAT(32), yes, and you can set this data as long as you have the correct permission for the files. This may be necessary for smooth operation of e.g. archiver tools and similar (as mentioned above), and since there is a separate permission system I don't see it as a flaw, but rather as a useful feature.

The question isn't really whether it's a flaw or design feature - it's whether it can be exploited. Thought NTFS had more security, though.

Fake

I meant "security flaw" as in "bad security design", which is quite inherent in your statement "Thought NTFS had more security". But again, you need to have write access to the file (which can be nicely controlled in NTFS, because it has just that, "more security" to be able to change its date, so I really don't see the security problem. If you have access to change the contents of the file, why shouldn't you be able to change the date of it? Not to mention that even if there weren't any direct APIs to do it, you could just change the system time and recreate/touch/read the file to set any date information you wanted anyway.

Actually, I meant: "thought NTFS had more security than 9x/me". In a, "thought so"-kinda way.

Generally, I just don't see much use for setting file date/time.

Fake

One primary use of making it possible to set the filedates manually is when you want to preserve the timestamps on files through some operations, e.g. the earlier mentioned compress/extract scenario, but also other scenarios like e.g. editing or writing metadata to media files (e.g. pictures taken with a digital camera). There are lots and lots of scenarios like this.

Unfortunately, it's also quite easy to hide changes to files that way.
I see pro's and con's to the stuff - don't really care much bout it though. If people want to wreak havoc or abuse the OS, there are worse things they can do.

Fake

Yes, many things can be used in one way or another to aid bad deeds, but it is practically never a good solution to remove these things for this sake though (bye bye internet?). Instead, it is often best to provide a security base that can be utilized to secure these items anyway. In this case this security base is the NTFS permission system. If we are talking about a user without admin permissions, the admin can set the permissions so that the user cannot modify the files (and thus not their dates either), and if we are talking about an admin level user, any malicious program he runs could bypass the file system layer and manipulate the file data directly on the disk anyway, even if there were no APIs to write to files without changing the dates, and no APIs to directly manipulate the dates either. So, then we would have removed this feature and all its "good" uses for nothing, making life more inconvenient for normal users, but still having just the same vulnerability as before. Finally, to cover any possible counter-example situation, if a non-admin user wants to be able to modify the contents of the files, but still wants to be able to see if the files have been modified by someone else, he should consider to accomplish this cryptographically (which will result in the bad guys not being able to edit the files undetected by any method, not even with admin rights and direct access), instead of trusting the security-by-obscurity-based method of not directly exposing certain functionality to normal users.

And yeah, sure, this example with filedates might be less significant than others, but it's this general philosophy and approach to security that I'm objecting against. It's quite a widespread and normal reaction though, but it practically never holds up in reality if you just think some more about it.

One doesn't need to remove it - just make it harder to abuse or screw up, by default.


And what about the files that the user needs to be able to modify? Perhaps if there were settings, so that only the system sets the time, but not allowing user time/date changes.

Ofcourse things can be circumvented, but rather that it be hard than easy.


Running admin priviledges is also a risk - it's the normal user that's the main concern to me.


Strange that you arrive at this conclusion.


"He should consider" ... which is of course true. The main problem arises when the normal user trusts the system that is not secure. The whole point of talking about the normal user is exactly that the normal user isn't always in a position to have the necessary level of information - how is the normal user to know how the date/time can be changed? Far as I remember, that's what started this whole thread.
I agree that there are good uses for functions like these. There are also very good uses for Outlook Express, however the program should be deleted at first sight - most of the problems with it, is that normal users don't have the information level necessary to determine what is a risk and what is not. And even though this may be a fault on the part of the normal user, the risk and damage is too high to disregard. There will always be stupid users, and blaming them won't help - making software secure will. This doesn't mean removing all functions, it just means making it as secure as possible.



Well, in general I agree with your attitude towards security - better to advance the level of knowledge than to try and remove the threat (since, by hypothesis, new threats will always arrive). However, there's two sides to the coin: the other hypothesis is that new fools are born every minute. As such, the only rational thing to do seems to me to be to raise the general level af computer-literacy, while striving to make software as secure as possible. In no way does this entail removing functions from software.

And, as I have stated already in this thread, I do believe that the security of file time/date is an improvement over 9x/me - security is in pretty much every way improved from 9x/me, which is very nice. This just doesn't mean that it can't get better - as long as normal users continue to get fooled (in one way or another, in regard to security in general) there is obviously room for improvement. Be it in the area of knowledge or software-security.

Scuze the ramble, btw.

Fake

care to what kind of exploits you could make out of changing File date/time?

You can only do it on files for which you have write access. Is there anything that relies on file date/time that would break if you changed them?

If a program can change the file time/date info on my files as long as I'm logged in, then the program can change those files without my knowing it. This is as it should be, since there are many good uses for this, as Delta pointed out.
However, the normal user has no reason to suspect that his files have changed if the file date/time info is the same - since, normally the time/date stamps do indeed change when you access the files (in cases of writing).
It's not really a question of whether anything would break or not - it's a question of the general users relying on something that may not be as secure as they think.

This may not be biggest security problem in Windows, by far. The question I'm asking is merely whether this design can be exploited, and whether it can be made more secure.

Fake

I think your view is somewhat contradictory.




When you make it "harder to abuse", the bad guys will still be able to do it, just like you say, but the only thing you might accomplish then is to make the users think it's even more secure (and remove functionality that may be beneficial to them at the same time), which is indeed a bad thing, just like you also say. This is also the exact same conclusion that you thought it was "strange that I arrived at".



Which is exactly what I meant about making the data tamperproof with cryptographical means on the application level (and no, the users don't need to write these programs themselves, it will be up to the applications that need their data to be tamperproof to do this), instead of restricting an operating system which cannot be ultimately trusted anyway (and no, I don't mean "Windows is not secure", I'm referring to the fact that the data cannot be trusted to not have been tampered with even if the operating system isn't exposing any APIs to do it, just like I explained before).



Exactly what do you propose to make the date/time functionality more secure without removing any functionality then, in addition to the NTFS permission system?



One of the biggest problems with "normal users" is that they are indeed logged in with admin privileges all the time...

If you limit the number of ways in which one can abuse the system, or screw it up, this makes it alot easier to determine whether foul play is at hand. If virii only had one way of propagating, it would severe limit the number of virii in the open. As it is, there are a lot of ways that virii can spread, and as a result a lot of computers are down every now and again.
Making the system harder to break indeed makes it more secure. If less people know how to break the security, that to me is a plus. There will always be bad guys out there, but that doesn't mean one shouldn't care about security, as your reasoning will lead to.


No. You, for some strange reason, argue that functions should be removed. This is a step of your reasoning I see no premises to accept. In fact, you were arguing that user options be restricted, so that the problem wouldn't be there - unless ofcourse you think that the only way to avoid the problem for users, is to remove the to permission to change files.


You're missing the point: if the general user doesn't know of the security holes, he's not going to use cryptographical means to secure his data. That's the whole point: if all users did, there wouldn't be a problem. However, a lot of users simply don't know that maybe there's a good reason to - and they will never know. Instead of waiting for the inevitable to happen, there may be a point in trying to increase the security of the OS. If the user can use cryptography on his own, it can be implemented in the system as well.


I'm not perfectly familiar with NTFS, but it seems possible to me, that one could implement a system log of file changes (can't remember if there's already something of the sort implemented). In addition to the date/time variables changeable by the user, an additional variable could be used, to keep track of last modification. The variable would be dependent on a system clock not modifiable by normal users.
As we already agreed, there's no point in implementing much extra security for admins - but these had better know what they're doing anyway. The real concern lies with normal users.


Some are, some aren't. If the security can be raised for at least some, that's still a step in the right direction, wouldn't you say? Or maybe everybody deserves what they get?

Fake

Hmm, that's odd, I thought I was the one arguing for providing a security base (the permission system) that could be used for secure usage, and you were the one that argued for removing features from the operating system that could be used for lots of other non-malignant things too...

Anyway, feels like we're going in circles here, I don't have the time to repeat myself again, and since I think I've made my point pretty clear (to most people anyway) I'll stop here for now.

Please provide a quote where I state that the date/time functions should be removed.

Actually, I'll have a try:

Well, if you'll equate "just don't see much use for" with "think the following functions should be removed:" I see your point. But maybe that's just a bit overinterpretive?
As a matter of fact, you're the only one who has suggested that upping security means removal of functions. I could be wrong tho - please point to where you think I suggested that any functions that could be abused should be removed.


Sure.

Fake