| |||||||||||||
The Journal - a proposed syslog replacement (is it really secure?)The Journal - a proposed syslog replacement (is it really secure?)Posted Nov 18, 2011 21:11 UTC (Fri) by nmav (subscriber, #34036)Parent article: The Journal - a proposed syslog replacement
I see the discussion that the method might be cumbersome to use, but I don't see any discussion on why this method is secure. My reading of it is that it doesn't add any security at all. If the only requirement is to keep the top hash in a read only location, then I just keep the top entry and recalculate the hashes of the next messages excluding the ones I want to delete.
Note that cryptographic hashes are _not_ digital signatures.
(Log in to post comments)
making the logs temper evident through git like hash chains Posted Nov 18, 2011 21:37 UTC (Fri) by scottt (subscriber, #5028) [Link]
> If the only requirement is to keep the top hash in a read only location, then I just keep the top entry and recalculate the hashes of the next messages excluding the ones I want to delete.
Each hash is calculated from the "payload" of the log entry and the hash of the previous entry. If you try to change a hash in the chain the hash of its descendant would no longer match.
This is how the Monotone, Mercurial and Git revision control systems work.
making the logs temper evident through git like hash chains Posted Nov 18, 2011 22:37 UTC (Fri) by nmav (subscriber, #34036) [Link]
Monotone, Mercurial and Git and not designed to protect against malicious attacks and as I said their method is not secure (that's why e.g. git allows digital signatures on tags).
making the logs temper evident through git like hash chains Posted Nov 19, 2011 0:27 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
Wrong. Git has been specifically designed to be secure from the start. That was one of its original design goals.
And it IS secure, signatures are used not to authenticate integrity, but to authenticate the author of changes.
making the logs temper evident through git like hash chains Posted Nov 19, 2011 4:40 UTC (Sat) by nevyn (subscriber, #33129) [Link] From: blog.valerieaurora.org talking about CAS and compare by hash...Finally, in a vain attempt to forestall the inevitable flame wars, I will point out that my objections do not apply to systems in which the hash address space is shared only with trusted users. In other words, hash-based source control is for the most part fine sticking with SHA-1 and could indeed use a cheaper hash like MD5 without any practical troubleFrom: kernel trap git archive on the first discussion about git only using sha1, Linus explains: As I explained early on [...], the _security_ of git actually depends on not cryptographic hashes, but simply on everybody being able to secure their own _private_ repository.Then there was another discussion, where other people said the same things. Git's use of hashes as a CAS doesn't make it secure, doing the same thing for log file lines will not make them secure/trustable/whatever either.
making the logs temper evident through git like hash chains Posted Nov 20, 2011 3:12 UTC (Sun) by cmccabe (guest, #60281) [Link]
SHA1 has been weakened, but many other hash functions have not. Given that security is the whole point, I'm sure that Lennart will use a newer hash.
making the logs temper evident through git like hash chains Posted Nov 20, 2011 19:19 UTC (Sun) by nevyn (subscriber, #33129) [Link]
I think you missed the point ... git and journald can happily use SHA-1 because it adds no security at all. git gets a bunch of other useful features out of using hashes, AFAICS it's just a waste for journald.
making the logs temper evident through git like hash chains Posted Nov 21, 2011 23:52 UTC (Mon) by cmccabe (guest, #60281) [Link]
> I think you missed the point ... git and journald can happily use SHA-1
> because it adds no security at all
Er, I think perhaps it is you who is missing the point. TFA says:
> Each entry authenticates all previous ones. If the top-most hash is
The point is to get security, not to "happily use SHA-1."
making the logs temper evident through git like hash chains Posted Nov 19, 2011 0:32 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
this means that you have to check the hash of every single line in the file to find a problem.
that takes a significant amount of time with a large logfile.
If you don't check every single hash, then the attacker deletes one entry and then two entries later the hash will compute
there's also nothing preventing the attacker from re-writing the entire file to have consistent hashes, but with missing entries (git allows this as well,I believe it's the filter-branch option)
If you have the ability to send stuff elsewhere to a secure location then you don't need this. If you don't have this ability, then this new stuff doesn't do you any good.
tripwire, ossec and equivalent already have the ability to learn that a file is a logfile and complain if an existing part of the file is modified between scans. There is a window of vulnerability in that they don't check after each line is written, but if you run them frequently you get something that's at least 90% as good, without having to throw out all the existing logging related tools in the process.
making the logs temper evident through git like hash chains Posted Nov 19, 2011 5:28 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link] there's also nothing preventing the attacker from re-writing the entire file to have consistent hashes, but with missing entries (git allows this as well,I believe it's the filter-branch option)That's true. The biggest thing it does is to increase the sophistication an attacker requires to cover his tracks thoroughly. Instead of editing a log file with his favorite text editor, an attacker will need a track erasing program that rewrites all the log files with suspicious entries removed and hashes recomputed. Of course once a program like that gets out, all the script kiddies will be able to use it and we'll be hardly any better off than today- securitywise, at least.
making the logs temper evident through git like hash chains Posted Nov 20, 2011 8:16 UTC (Sun) by drag (subscriber, #31333) [Link]
Well that's the obvious first thing one should think of. I thought of it too.
Then I read in the article about a mythical 'Write-once storage'. If you can write out the hash to a write-only interface then that would solve that problem.
Unfortunately I don't know of a good write-once media. Maybe cdroms, but I don't know about that.
Maybe special flash media with the 'erase block' part of the hardware disabled and a logging FS. I don't know.
It is a solvable problem, but not one that is as easy as first glance.
making the logs temper evident through git like hash chains Posted Nov 27, 2011 2:18 UTC (Sun) by rgmoore (✭ supporter ✭, #75) [Link] But the big security benefit in that case is from the existence of the WORM memory, since any data written to it is inherently tamper-proof. You could stick to an un-hashed text log and still have confidence that it hadn't been rewritten by an intruder. The benefit of the hash chain is that you can provide tamper evident recording by keeping only a fraction of the hashes, which is most important if the WORM storage is expensive or difficult to deal with. Of course keeping only a fraction of the hashes leaves open a potential window if the attacker can break in an alter the records between writes to WORM.
making the logs temper evident through git like hash chains Posted Nov 27, 2011 5:47 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
however, since systems don't actually include WORM memory, and are very unlikely to (except for very specialized systems), how does that actually help?
remember that WORM memory needs to be a replaceable thing since by default you can't erase it to make room for new data.
|
|||||||||||||