Jump to content

Talk:Log4Shell

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Date format

[edit]

This article currently uses DMY dates, but Log4j and other technology articles use MDY dates. I think it would be worth switching for consistency? ―Jochem van Hees (talk) 12:35, 13 December 2021 (UTC)[reply]

Agree - User94729 (talk) 14:00, 13 December 2021 (UTC)[reply]
I don't think there's a specific policy on technology articles, but we should definitely be consistent, so I agree. Ovinus (talk) 16:22, 13 December 2021 (UTC)[reply]

@Dl2000: hi, I don't understand this edit. How was that a "recent test"? ―Jochem van Hees (talk) 09:23, 14 December 2021 (UTC)[reply]

In general per MOS:RETAIN, there probably wasn't a need to change it either. I doubt one related article using it reduce ambiguity or similar (if it does, I wouldn't be opposed to changing the variant) — Berrely • Talk∕Contribs 20:30, 14 December 2021 (UTC)[reply]

Technical explanation

[edit]

I was going to add a more in-depth explanation of how the vulnerability works, maybe a couple paragraphs, but thought I should see what others think. It definitely has encyclopedic value by showing anyone with moderate computer knowledge how simple and dangerous the exploit is, and I doubt including it has any ethical concerns given how widespread information about it is—including on major tech websites. For reference, Heartbleed#Behavior has a section explaining it, albeit poorly cited; Shellshock (software bug) has pretty extensive detail, including exploit code. Ovinus (talk) 14:38, 13 December 2021 (UTC)[reply]

You actually posted this while I was also looking into writing an explanation; it really could do with one. Currently the article doesn't even mention that it is triggered by pasting a certain string somewhere to get it to be logged, that seems like it is like basic information about the exploit. ―Jochem van Hees (talk) 14:50, 13 December 2021 (UTC)[reply]
@Jochem van Hees: Agreed. User:Ovinus/sandbox contains my draft. Cheers, Ovinus (talk) 15:16, 13 December 2021 (UTC)[reply]
I think that's pretty good! For that citation needed at the end, I also found this source which also goes more into depth about the environment variables thing (in section 8): [1]. ―Jochem van Hees (talk) 15:32, 13 December 2021 (UTC)[reply]
Awesome, thanks a ton for the source—I was struggling to find something reliable of that detail. I've put it in the article now. Ovinus (talk) 15:42, 13 December 2021 (UTC)[reply]

Used before published, or published before used?

[edit]

The article is written like it was published before people used it, but all the articles call it a "zero-day" implying that the attack was being openly used before it was published. I can't find a good way to confirm this either way. 142.55.0.16 (talk) 15:14, 13 December 2021 (UTC)[reply]

All I have been able to find is that the CEO of Cloudfare, Matthew Prince, tweeted that the earliest evidence of the exploit was on December 1. I don't know if that can be considered a reliable source though. ―Jochem van Hees (talk) 15:34, 13 December 2021 (UTC)[reply]
Prince was quoted in this ZDNet article, which I think qualifies. And anyway, more and more sources will write about it, especially non-technical details like that. (As an aside, I'm really surprised how long it took for major news sources to pick this up; this could be one of the most consequential exploits in history....) Ovinus (talk) 15:46, 13 December 2021 (UTC)[reply]
Matthew Prince didn't specify how many exploit attempts there were before public disclosure and whether the attempt he found was actually trying to be malicious, so I think it might have also just been the discoverers trying out which services are affected (which they did, to create the screenshots circulating around). - User94729 (talk) 15:53, 13 December 2021 (UTC)[reply]
Oracle issued a patch for their JDKs in mid 2020, patch number 32105696, which appears to mitigate the related CVE-2021-4104 log4j1 exploit. I wonder how much they knew and when they knew it -- Mark J (talk) 17:19, 8 January 2022 (UTC)[reply]

Media coverage

[edit]

This article has been mentioned in the media, or at least an omnibus blog. kencf0618 (talk) 20:46, 14 December 2021 (UTC)[reply]

https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

That article mentions the Log4j article, not this one. Added a {{press}} template to the talk page there. ―Jochem van Hees (talk) 21:00, 15 December 2021 (UTC)[reply]
Thank you. kencf0618 (talk) 20:52, 17 December 2021 (UTC)[reply]

The 8u121 fix

[edit]

17:39, 15 December 2021‎ User94729 Undid revision 1060445070 "the fix in 8u121 was found to be insufficient to block this vulnerability until later versions,"

I do not understand this. The fix is sufficient to block remote class loading via JNDI.

Olekva (talk) 20:42, 15 December 2021 (UTC)[reply]

" and even then, there are still vulnerabilities in certain applications"

Which applications? Is it applications where com.sun.jndi.rmi.object.trustURLCodebase or com.sun.jndi.cosnaming.object.trustURLCodebase has been set to true?

Olekva (talk) 20:42, 15 December 2021 (UTC)[reply]

See this link I just added as a citation. LDAP remote code loading was disabled much later in 8u191 and classes may still be loaded through other local classes in the classpath. Also, please wait for response from other editors before reverting the changes under discussion. - User94729 (talk) 20:59, 15 December 2021 (UTC)[reply]
[edit]

The original severity of this CVE was rated as Moderate; since this CVE was published security experts found additional exploits against the Log4j 2.15.0 release, that could lead to information leaks, RCE (remote code execution) and LCE (local code execution) attacks.

Apache changed Base CVSS severity rating from 3.7 to 9.0

https://logging.apache.org/log4j/2.x/security.html

Question: Add CVE-2021-45046 to Log4Shell article OR new article for CVE-2021-45046? Luamssuk (talk) 11:47, 17 December 2021 (UTC)[reply]

Unless the press/researchers start reporting about this vulnerability as substantially distinct from the first, I think keeping it as a redirect is fine. But highlighting the severity is definitely a good idea, since many people thought upgrading to 2.16.0 wasn't a must. Cheers, Ovinus (talk) 12:10, 17 December 2021 (UTC)[reply]

Did you know nomination

[edit]
The following is an archived discussion of the DYK nomination of the article below. Please do not modify this page. Subsequent comments should be made on the appropriate discussion page (such as this nomination's talk page, the article's talk page or Wikipedia talk:Did you know), unless there is consensus to re-open the discussion at this page. No further edits should be made to this page.

The result was: promoted by Theleekycauldron (talk) 10:26, 20 December 2021 (UTC)[reply]

(
)
  • ... that Log4Shell has been called "the single biggest, most critical vulnerability ever"? Source: Barrett, Brian (16 December 2021). "The Next Wave of Log4J Attacks Will Be Brutal". Wired. ISSN 1059-1028. Retrieved 17 December 2021.

Created by Vulpicula (talk). Nominated by Jochem van Hees (talk) at 12:26, 17 December 2021 (UTC).[reply]

General: Article is new enough and long enough
Policy: Article is sourced, neutral, and free of copyright problems
Hook: Hook has been verified by provided inline citation
QPQ: Done.

Overall: Looks good to go on my first pass. I prefer ALT1, followed by ALT3, as it seems to be less opinionated. ALT2 would also be great, but needs a better source and is not explicitly mentioned in the article. SounderBruce 19:21, 19 December 2021 (UTC)[reply]

Tweaked ALT1 to T:DYK/P2
[edit]

A logo for the log4shell vulnerability has been added quoting it is "widely used". I have not seen any wide use of such logo, indeed the notion that a vulnerability has a trademarked logo is somewhat preposterous. Removing the logo from this article for now, but happy to discuss if there is evidence of "wide use". pseudonym Jake Brockman talk 08:00, 22 December 2021 (UTC)[reply]

Vulnerabilities sometimes do get their own logos. Have a look at Heartbleed, for example. No comment on this one though. Stephen 23:40, 22 December 2021 (UTC)[reply]
I've seen the 'logo' around places, but that doesn't justify the "widely used" part in the caption. Though I'm used to seeing it, still I think it should remain. It's quite identifiable imo. After all, it's available with an Apache 2.0 license (from what I could tell from the GitHub repo). ...indeed the notion that a vulnerability has a trademarked logo is somewhat preposterous. It's a joke. You can just put TM on anything if you wanted. SWinxy (talk) 04:22, 23 December 2021 (UTC)[reply]
At the very least, if this logo is kept it should be explained in the article, especially if it's a joke. And since such an explanation would likely not go in the lead, the logo shouldn't be there either. And now that I think about it a section about a fanmade logo is really not significant compared to the topic as a whole. I'd just exclude it. ―Jochem van Hees (talk) 10:02, 23 December 2021 (UTC)[reply]

Usage vs Response & Impact

[edit]

I kinda fail to see why these are separate sections? Isn't the way a vulnerability gets exploited part of the impact? ―Jochem van Hees (talk) 10:19, 23 December 2021 (UTC)[reply]

Yes. I think this article would benefit from a rewrite once the dust settles. LondonIP (talk) 02:44, 26 December 2021 (UTC)[reply]

Tense

[edit]

Should the article be in past tense, as it was patched? 2603:6080:A601:9600:5D3B:9394:9FE4:A6B0 (talk) 21:25, 11 August 2022 (UTC)[reply]

No, software-related articles are usually written in present tense. Besides, I’m pretty sure there are still plenty of servers running a vulnerable version even 10 years from now. NM 21:25, 17 September 2023 (UTC)[reply]
In addition to present tense, the first sentence says it's a "zero-day" vulnerability. Whether zero-day is interpreted literally or as a fixed phrase, I don't see how Log4Shell can still be a zero-day vulnerability. In addition, Wikipedia guidelines advise against references with relation to the present day, as these are, by their very nature, doomed to become outdated. EditorPerson53 (talk) 00:08, 9 December 2023 (UTC)[reply]

Requested move 11 October 2024

[edit]
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: not moved. (closed by non-admin page mover) Reading Beans, Duke of Rivia 10:46, 26 October 2024 (UTC)[reply]

Log4Shell → Log4j vulnerability – Per WP:COMMONNAME, the name of the library is more commonly used than the name of the exploit. PhotographyEdits (talk) 11:31, 11 October 2024 (UTC) — Relisting. Fathoms Below (talk) 15:32, 18 October 2024 (UTC)[reply]

Oppose - WP:COMMONNAME does not make sense, we could technically move Heartbleed to OpenSSL vulnerability but we don't cause that would confuse the reader. Log4Shell refers to a specific group/type of vulnerability the Log4j library that can be exploited through the injection of arbitrary JNDI input. Moving the page to "Log4j vulnerability" would be a step backwards in terms of understandability and specificity since that can be used to describe any (and all) vulnerabilities in the Log4j library. Sohom (talk) 20:36, 14 October 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Log4Shell&oldid=1253508840"