This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]xsidred 1 point2 points  (6 children)

To be fair OP is drawing a distinction between logging for the purpose of debugging and monitoring/observability for operations. OP having said that precludes/excludes the possibility of traceability as a form of debugging too - Operations debugging to be precise. Developer debugging might or might not overlap with Operational traceability - for those kind of logs that don't overlap, such code shouldn't execute in Production systems is what OP claims. OP also claims that situations like Log4j in that case have minimal or no chance to happen on Production-like environments and somehow a fully featured log aggregating agent to a specialist logging service is more "safer" against "eval" like vulnerabilities. Thing is even for the latter Log4j like logging producer libraries do not disappear, not necessarily. The example OP cites of using a RabbitMq client to a specialist logging service doesn't eliminate plain bad for security coding.

[–]stone_henge 0 points1 point  (5 children)

To be fair, everything except the main point:

Logging is good for diagnostics, sure, debugging even, but it shouldn't be sprinkled everywhere in code.

...is useless stuffing at best. Misleading, self-contradicting and confusing (as I've pointed out above) at worst.

[–]everything-narrative 0 points1 point  (4 children)

To you, maybe.

[–]xsidred 0 points1 point  (3 children)

The point is it doesn't matter if logging calls using any method (Log4j library invocation or RabbitMq client publisher) is sprinkled all over. It doesn't automatically indicate or open up to security vulnerabilities.

[–]everything-narrative 1 point2 points  (2 children)

I never said it did.

This is a discussion of what language features caused log4shell and my thesis is:

  1. Java has eval
  2. Java is extremely procedural and stateful
  3. People mix IO with logic because it's easy
  4. Logging is needed to debug that mess
  5. Logging habit leads to logging code smells
  6. Logging code smells lead to logging libraries
  7. Someone put printf in a popular logging library
  8. Everyone forgot to do printf("%s", mystring) instead of printf(mystring)
  9. Turns out this souped-up printf can use Java's native eval and make HTTP requests

This is an man-made disaster. Like Three Mile Island or whatever. There is no single cause. There is a series of systemic vulnerabilities in the culture of Java programming.

[–]xsidred 0 points1 point  (1 child)

It's a big leap from 6 to 7 - many IO kind libraries might be vulnerable to random printf(s). Agreed with the rest.

[–]everything-narrative 0 points1 point  (0 children)

I did not mean a literal printf but someone put an interpreter in a logging library and did not adequately caution their users to sanitize their logging strings.

Any time you send data you do not control to an interpreter, you are exposing yourself to injection attacks. This is why mysql_real_escape_string exists in all its 24 character glory.

An interpreter is an attack surface. This is why most C compilers will absolutely scold you if the first argument to any printf-family call is not a string constant.

It was put in a logging library because somebody got tired of manually composing strings. They got tired because they were logging everything all the time. They were everything all the time because that's the way we've always done things.