Comments on Rainer's Blog: journald log hash chaining is broken

In general, discussion seems to tell that people l...

2011-12-05T14:27:55.859+01:00

In general, discussion seems to tell that people like the idea of hash chains (no matter which issues exist ;)). If so, than that idea is probably useful not only for journald, but also for syslog AND also for other log files as well. Consequently, I have begun to work an a tool that will hash-chain any log file (plus a small lib that offers this functionality). I intend to also make it self-verifyable via real signatures in the somewhat longer term. I'll post an announcement when the first version is ready (it's a simple standard *nix filter).

Thanks for your answer. I think you are handling t...

2011-12-05T14:19:43.056+01:00

Thanks for your answer. I think you are handling the "issue" gracefully -- which is nothing serious anyway, making occasional mistakes is human.

I think Frank Ch. Eigler is spot on: saving a hash is more convenient than saving the logs because its space usage is constant, as well as the time needed to check its correctness (in the "chain" case). This allows you to save the validity data in more places and check it more often.

That said, your concerns are also valid: you need a secure process of how/when/where to save the chain -- though I'm not sure it's something cryptography experts would handle that more precisely -- and you will eventually also need to save the full logs in a secure place anyway. It's more of a complementary quick-and-simple checksumming technique.

I have to add to the tone: when I read what was pr...

2011-12-03T11:44:11.350+01:00

I have to add to the tone: when I read what was proposed, I really thought "how silly can someone to actually propose that?" and I seem to have conveyed that thought ;-)

Again, the hash chaining is still silly, especially as no point is made how, how often, when and with wich permissions hashes are saved. I still think this is "datasheet cryptography" and it is very dangerous if you think you are secure just from using journald.

I have also updated to post with the information that one should read the comments before coming to a final conclusion.

You are right with the observation, but please rea...

2011-12-03T11:37:29.531+01:00

You are right with the observation, but please read the other comments -- they both tell the basic misunderstand and why the proposed method still does not solve the issue (at least not more than the traditional methods already used). It is also important to read the links to the papers I posted.

I should probably write a new posting on the issue. I have also learned that many folks seem to find hash-chaining useful (even though it has serious flaws). For that reason, I have written a prototype that does hash chaining, to be released soon. That effort, however, will be amended by some cryptographically sound method.

On the tone: I had writen this shortly after reading the journald proposal. Maybe I important some of their tone ;)

You completely missed the point of the proposed se...

2011-12-03T10:10:31.348+01:00

You completely missed the point of the proposed security method. He assumes that you have regularly saved the top-most hash. When checking if a given message chain may have been manipulated by an attacker, you have to :

1. Check that the top-most hash you remember is present somewhere in that chain

2. Check that the sub-chain that ends with this hash is validly hashed (eg. each hashing step is correct).

If you perform this method (and you hash function is secure enough), you are sure that no malicious modification was done in the sub-chain that ends with this hash. (Indeed you don't know about the newer part, because you haven't saved any information on that)

In your post, you only used method (2). Indeed this check is meaningless without check (1). The fact that you completely missed step (1) and didn't even mention it shows that you did not understand the proposed security measure.

This is not meant to be an attack: I read your "Serious syslog problems" post with great interest and completely agree with you that anything security-related needs to be confirmed by actual security expert. I came reading this post assuming that you had discovered a real flaw in the proposed technique, and am simply disappointed.

No harm meant, but still the rather triumphal tone of your post hurts, I think, your credibility.

"Anyhow, so what does the proposal (if meant ...

2011-12-02T20:55:54.352+01:00

"Anyhow, so what does the proposal (if meant as you say) offer over directly writing to a write-once medium (as data centers today do with important logs)? "

Only hypothetical space savings.

Well, in a paper on logging, it probably is a good...

2011-11-28T12:05:07.019+01:00

Well, in a paper on logging, it probably is a good idea to use logging terminology. I find it a bit inappropriate to talk to a community and not even try to understand the commnunities terms...

Anyhow, so what does the proposal (if meant as you say) offer over directly wiriting to a write-once medium (as data centers today do with important logs)? (I have to admit I thought something novel had been in the approach...)

Lennart was "inspired by git". In git th...

2011-11-28T11:36:58.318+01:00

Lennart was "inspired by git". In git the "top-most commit" usually means the HEAD, i.e. the newest one. I am reading the papers, thanks for the links.

Oh, and as a side-note: what's the difference ...

2011-11-28T11:15:14.266+01:00

Oh, and as a side-note: what's the difference then to writing all log entries to a write-once media? You can do this with syslog today ;-)

That's right, but this means the write-once lo...

2011-11-28T11:13:43.452+01:00

That's right, but this means the write-once location must be continously updated, as each record is written. Or maybe every ten minutes, if it is OK that 10 minutes of attack can go undetected. Also, if this is saved all so often, the write-once memory seems to be accessible, so as an attacker why not add the new hash there, too? Also, the journald paper says "If the top-most hash is regularly saved to a secure write-only location", with top-most usually meaning the "oldest". Anyhow even if you save the youngest hash in short intervals, this is not how crypto works. Read the papers to which I linked to see how it is done decently.

I don't follow your reasoning in the example. ...

2011-11-28T11:07:31.672+01:00

I don't follow your reasoning in the example.
Yes, the attacker can delete the 10 records and recalculate the hashes of the following records. And yes, the hash chain as such will be fine afterwards. But the previously recorded hash of the 2000th record (in a write-once location) will then be nowhere to be found in the new hash chain, will it?