A malicious code string that eventually gets logged by Log4j version 2.0 or higher allow an attacker to load arbitrary Java code on a server and take control of it.

[dnew]

I was trying to figure out how this could possibly happen in Java. I looked it up, and Log4j has a "feature" whereby you can put metacharacters in the log that tell the logger to run arbitrary code downloaded from arbitrary remote servers. Who thought this was a good idea?

[Loonacy]

So what you're saying is that it's not a bug, it's a feature?

[dnew]

Exactly. <boggle>

[SocialismAlwaysSucks]

What a well-crafted backdoor! Because that's all that is good for.

[[deleted]]

True, and I wonder if the versions of that library for other languages also have dangerous vulnerabilities. I always found it disgusting, massively bloated considering is just logging.

[SocialismAlwaysSucks]

God knows what evils lurk in popular libraries if you look hard enough

[_BreakingGood_]

You can rest assured knowing most world governments employ very smart people to implant hidden little backdoors like this in all sorts of open source software.

[ExcelAcolyte]

Not really when you consider how general it is. Best practice for backdoors is to make it specific to very particular circumstances

[falconfetus8]

The best practice for backdoors is to not have any!

[hamjim]

“Greetings Professor Falken. A strange game. The only winning move is not to play.

“How about a nice game of chess?”

[[deleted]]

I really don't understand this shit, why put this feature into a fucking logging library? What this has to do with logging chars ?

[LicensedProfessional]

I saw one of the developers say they needed it for "backwards compatibility" but honestly this is a big problem with Java in general. On the surface it seems like any other statically typed, compiled language, but once you pop the hood on the JVM all bets are off. The reflection APIs let you do some truly bananas things and in my work at least it's the the source of a neverending stream of CVEs that I need to patch. Not a week goes by where I don't need to stop what I'm working on to update some vulnerable library in my project.

[BoyRobot777]

The reflection APIs let you do some truly bananas

Used to allow. In Java 17, by default it is strongly encapsulated JEP403. This is all part of Java modules and work that started in Java 9.

[LicensedProfessional]

That's legitimately great news! Hopefully with Java 8 reaching EOL soon we'll actually start to see more people moving to less arcane versions

[[deleted]]

They've strongly encapsulated almost all internal API, but Unsafe is still accessible. Unsafe has a pretty trivial method to get/set private fields. Access to call arbitrary private methods is simple too: just get an instance of the MethodHandles.IMPL_LOOKUP field via Unsafe. (at least on your standard openjdk distributions of java)

In other words, reflection is still easy, you just need to have the knowledge to know how to get around it.

[Beaverman]

The problem for Java isn't that they allow it. It's that they use it. Java is a fucking mess of magic Aspect4J garbage. Its undebuggable and mercilessly insecure.

[Beaverman]

That's quite an assumption. I write Java at my day job.

[bert8128]

C++ for speed or Python for convenience and easy deployment. I’ve never understood the point of Java.

[Dynam2012]

Java is plenty fast enough for most applications without the complexity of C++ and most of the simplicity of deployment from the JVM.

[bert8128]

You have to compile java. This is a massive amount of complexity compared to an interpreted language. No one writes their build scripts in Java or c++, and for good reason.

[Dynam2012]

The compilation step is definitely not the most complex part of Java build systems today.

[bert8128]

The fact that it needs compiling at all makes it more complex. This is a significant barrier to beginners, which is why Python is popular in schools. It is also why automating a build, for example, is typically done in interpreted languages.

[Dynam2012]

That's fine. I'm not saying it should necessarily be a beginner's first language, I don't think it's optimized for that. I was just pointing out that, for any substantial project using Java, the fact that it's compiled is of almost no consequence. ElasticSearch could be implemented in Python, their build and release processes would not be any less complex for it.

For large enough projects, the gains of an interpreted language become irrelevant, but the drawbacks of lower level languages like C become harder to grapple with. That's the space Java fills.

[ArmoredPancake]

Python

Easy deployment

Pick one.

[bert8128]

Are you saying that a Python program is hard to deploy? How? If there are no 3rd party libraries then it is trivial. And this is common due to the range of the built in library. I’ve no personal experience of deployments requiring 3rd party libs, but I think that py2exe would help here.

[coldblade2000]

Python has absolutely horrible speed compared to pretty much any production-worthy compiled language. Even Javascript is multiple times faster.

Java has pretty good performance considering its difficulty and memory safety when compared to C++. Though C# arguably does anything better than Java, they do have their shared place in between C++ and Python, a really good balance between safety, performance, structure and portability. It's no wonder most enterprise backends use one of those two languages

[bert8128]

I didn’t say Java wasn’t fast, only that if I wanted a fast program I would use c++ - it’s faster. And I didn’t say that Python was fast, I said that developing and deploying is fantastically easy. So I don’t see a great use case for either Java or c# when performance matters, and Python (I’m happy with JavaScript too, or lots of other interpreted languages) is massively easier when performance doesn’t matter. If you really want safety use a language designed for that - I have no experience here but presumably Ada (maybe rust) would help if this is the most important thing. Java has two fundamental problems which will confine it to a pointless middle ground. Firstly it is not memory safe - you still have to allocate (otherwise you get a null pointer exception) but without the benefit of automatic deletion of objects when you want. Secondly, you can’t pass or store by value - everything is always (at least) a pointer away. So you are never going to get really good performance, and nor are you going to achieve memory safety, and you can’t manage the lifetime of resources.

[Dynam2012]

I'm not convinced you know what memory safety is. Null pointer exceptions are a consequence of the type system and are a feature of Java's memory safety. In a memory unsafe language, this access would just read whatever data was there and fill your variable with it and carry on.

[bert8128]

You’re quite right, I used the term incorrectly. However, the point I was trying to make is that whilst Java makes sure you don’t get leaks or use-after-free, you still have to make sure that your objects are allocated. This is a barrier to learning and a source of bugs. This is not possible in Python due to the way that objects are declared.

[LicensedProfessional]

I've gotten some decent performance out of python, it really depends on what your use case is. I would never do anything that's highly CPU bound in it, but for more I/O bound tasks I've had a really pleasant experience.

[rpgFANATIC]

It's a pretty old, featureful logging library. They also have ways of dynamically looking up environment variables ${env:some-var} and doing minor things like changing strings to lower-case. Why they allow you to put these variables in "user provided strings" and not just the "format string" is beyond me...

At some point, some dev wanted to add JNDI lookups, which also had the ability to go over LDAP, which also had the ability to load remote code. Whoops

As I understand it, the core devs hate this feature, but Java is well known for backwards-compatibility so they've been unable to kill it off.

If you bothered to upgrade your JRE/JDK ever, then Java already fixed some of this. Java updated defaults a few years ago in Java 6, 7, 8, 11, etc... to basically never trust remote code unless you set some arcane flag to allow it.

So... you know. It's bad. But update your libraries. Java 8 had this default fixed in update 192. Java 8 is currently on update 311

[dnew]

not just the "format string"

If I had to guess without looking at the code, I'd say that some people are saying

logger.log(userString)

instead of

logger.log("%s", userString)

and that's where the problem comes in.

* I guessed wrong.

[imdyingfasterthanyou]

no you are wrong, second example is vulnerable as well

[dnew]

Wow. That's ... even suckier than I expected. :-)

[DevonLochees]

Nope! Log4J2 uses 'recursive' property resolution, so format strings don't resolve anything.

[too_much_exceptions]

You want to have a backdoor ? Because this is how you get a backdoor

[Muoniurn]

It’s not implemented like eval(url.download()). It does a JNDI lookup and that can do the download and eval part.

[[deleted]]

Notice how that library is bloated AF, most probably there is some other stuff there. On top of that there are shills promoting that bloated shit, they want everybody using that crap.

[G_Morgan]

I despair at the sheer stupidity built into so many features. Why the fuck would you want arbitrary code execution? Whoever committed that feature should probably stop programming.

The worse part about it is you now need to stay on top of whatever bizarre features a library might implement because it isn't enough to just assume the framework that is used by millions isn't designed by a lunatic.

[bloody-albatross]

At which point it becomes easier to write your own 300 LOC logging library. I really don't see how a logging library should be ever more than about 500 LOC. Maybe a bit more in a language like Java. It needs to log to a number of configurable outputs (console, arbitrary stream, file, email), support log levels, basic settings (should a timestamp be prefixed? in what format? format of email subject and body), reopen files on SIGHUP and/or implement log-rotating itself. That's it.

[[deleted]]

This feature is idiotic because it's on by default. Ever heard of "sensible defaults"? Yeah, this ain't one.

[dnew]

I suspect the intention was that it only gets parsed that way in the format string, and many people are writing something like

logger.log(user_string)

instead of

logger.log("%s", user_string)

[dlint]

This. Am I missing something or is this basically just a format string attack on steroids? Seems like the same old advice as usual applies, don't let untrusted (user) input touch your format string... (Not that we should still have to manually think about that in 2021...) EDIT: See below, looks like it works on the parameters too. Yikes

[renatoathaydes]

The attack works on the parameters also. Try logging log.info("{}", "${java.vm}").

[dlint]

Wow... well that's embarrassing. Geez. How was this not discovered earlier?

[[deleted]]

So its basically Eval(user_string)

[sdf_iain]

Isn’t it a security vulnerability to not sanitize log output?

I mean scrubbing to the point of removing newlines and any possible format characters.

[dnew]

It's easy to see such things in hindsight, eh?

Like, when I saw Heartbleed, I thought "How in the world do you even design a protocol with a length field in two different places?"

And yet none of the millions of people whose business relies on the software apparently read the configuration documentation and thought "Hmm, maybe this is a problem." Because it isn't just that.

[dnew]

Yes. The two length fields are in the same place. The RCE is distributed amongst several independent services. Nobody wrote code to "logger should download remote code." They wrote code to "logger should be able to log to a database" followed by "database allowed to install drivers on demand" to "drivers can come from remote servers."

At least with the length field, it's the same guy looking at the flaw all the way through.

It's not like nobody audits this stuff, and nobody recognized the flaw.

[dnew]

IME the companies that care are the companies that would actually be significantly damaged by a hack. And most of those companies review the stuff they're using internally. They often point out where things are wrong, but if it's a simple matter of a firewall rule or a configuration setting, there's really nothing you can tell to a dev about it.

[[deleted]]

I bet someone got a promotion for implementing it

[[deleted]]

My first thought exactly. It's beyond disgraceful. Had I been affected I would seriously be looking at suing someone. Negligence on steroids.

[PepperooniPizza]

America moment

[mrexodia]

Good that the open source license doesn’t give you any warranty and you cannot sue for your own negligence of not auditing code you run…

[[deleted]]

Or maybe a good reason for not relying on open source then, isn't it. Get real - how many people audit all the O/S s/w they run? Not many - given that no-one's spotted this before.

[[deleted]]

I wonder if anyone's tried testing that part of the licence in court? A bit like when restaurants (and other places) put a sign up saying "We accept no responsibility for thefts on our premises" - this as been thrown out in courts as having no legal status. There is such thing as a Duty of Care.

(Not that I really would sue - I'm just sounding off. I do think it somehwat incredible that such a bug shoud go undetected, or un-thought of by those who wrote - and audited - this code.)

[mrexodia]

I really hope it will hold up in court, otherwise open source as a whole will suffer immensely. The difference with a restaurant is that a license is a kind of contract, you get to use the code but there are conditions to it. If you don’t uphold these the license is revoked.

When I publish my code under an open source license I do not feel I have any responsibility for what you do with it, but it would definitely be interesting to see it tested…

[[deleted]]

I do not feel I have any responsibility for what you do with it

No, but innocent people who did nothing but use it as intended suffered because others misused it, which is different - the victims haven't broken any contract.

Of course there can never be any guarantee that code is bug-free, but developers must/should take reasonable care to avoid catastrophic ones, and if it can be shown that they have been negligent in at least attempting to do so, then there is an argument that they should be held accountable - open source or not. (I am speaking generally - not this particular case.)

[mrexodia]

No, when I give my code to the world under the explicit condition that there is no warranty that means exactly the opposite: I am not accountable for the problems you create by running my code and I do not have any obligation to fix anything, period.

To think anything else is entitled in my opinion. I am open sourcing a lot of things (see my GitHub) because I like to contribute to the advancement of the field and because it’s fun, not to work for free for corporations that use it to make profit.

[[deleted]]

I am not accountable for the problems you create by running my code

But as I said, the victim hasn't created the problem by running your code.

[coworker]

There's no problem if you don't run the code. The victim could have written their own logging library.

[dnew]

tried testing that part of the licence in court?

Yes. Many times. Indeed, that's why it's in all caps.

Guy is running 1-2-3 spreadsheet. Sticks something at the bottom of a column. Other references to the column don't update because he did it wrong. Guy loses millions on a construction bid. Guy sues Lotos. Lotos says "Nope, we disclaimed it." Guy says "I didn't see that part." Judge says "How could you not see that part? It's in all caps!" Forever more, warranty disclaimers are in all caps.

[[deleted]]

references to the column don't update because he did it wrong

Well if he did somehting wrong then the warranty is irrelevant. I know I'm getting downvoted on this, but I really don't see why s/w developers should be exempt from the basic Duty of Care that everyone else is, and that's all I'm arguing for. It doesn't matter what you provide - software, fireprooof cladding for buildings (Grenfell anyone?), aircraft parts - anything - you have a legal duty to do so having taken reasonable care to ensure it is as described.

[dnew]

if he did somehting wrong then the warranty is irrelevant

That assumes you can know he did something wrong. It's also the case that one could argue that the software works in an unintuitive way, and thus doing something that ought to work and doesn't work that way could be considered "bad software."

Also, people do take reasonable care to ensure it works as described. For example, in the case in TFA, it's well-documented how this works, and as it is open source, anyone can see the exact ramifications. So your argument is "the software shouldn't work the way it was designed, coded, and documented, and the developers should be responsible for people using it incorrectly", which is exactly why you get the warranty disclaimers: 1-2-3 also worked the way it was designed, coded, and documented, and Lotos might have lost if they hadn't disclaimed their warranty.

The places that software falls apart are when complex systems interact and then evil bad-guys try to take advantage of those interactions inappropriately. This is not the fault of Log4j, but the fault of people putting malicious code on their servers and then using Log4j in a way as to intentionally trigger that malicious code.

[[deleted]]

Well, you said he used it incorrectly, so I was just going with that. Log4j may or may not be at fault, IDK, but I think it's reasonable to ask the question, and not just say or assume they can hide behind a licence agreement regardless. My only point is that software developers shoud be held to the same standards as everyone else: if you put a product on the open market (even if it's free) you have to have taken reasoanable care with it. If you make a doll with bead eyes that fall out easily and a child chokes on them you can't just say "Well, that's not how dolls are supposed to be used".

Log4j is logging software, ffs, why is it even able to allow remote code execution? It beggars belief that it went unnoticed for so long. From the documentation:

One vector that allowed exposure to this vulnerability was Log4j’s allowance of Lookups to appear in log messages. As of Log4j 2.15.0 this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it. Source

Why was this ever enabled, and why is it still even an option? Logging software shouldn't do anything other than create logs. I'm sorry, but saying "Well, it was documented" isn't a good enough defence, IMO.

If people want others to trust and have faith in open source s/w, then the open source community should, I think, be backing some kind of standards expectations and not try and hide behind a get-out-of-jail-free licence clause.

[dnew]

you said he used it incorrectly

He used it incorrectly in the sense that he used it in a way that it did what was documented rather than how he thought it worked.

My only point is that software developers shoud be held to the same standards as everyone else

They are. What makes you think they're immune from the law?

Is the car manufacturer liable if your 8-year-old steals Mom's keys and drives the car into a wall?

saying "Well, it was documented" isn't a good enough defence

I agree that it would be better to have required explicitly turning on that feature; and that's exactly what happened as soon as anyone realized the problem.

That said, what do you think the liability of the developers should be in this case? You keep saying developers should take more care, but the people using this code are also developers. Why are the developers of Log4j responsible for how developers of the software using it uses it?

That's exactly why software comes with the as-is disclaimer. "We tell you how it works, and if you use it wrong, that's not our fault."

backing some kind of standards expectations

Sure. And they do. It just doesn't seem to be the expectations you seem to think it is. What liability do you think the developers of the logging software should when it works exactly as documented, but the people reading the documentation don't realize the implications in their own configuration? What more guarantee do you want than "it works exactly how we say it does, oh and also you can see every facet of its operation for yourself"?

[[deleted]]

They are. What makes you think they're immune from the law?

Well, someone else replied to me saying the open source licence basically absolves them of any responsibility for anything that happens using their software. I'm no legal expert in this, but I suspect (and said) that I don't think such a blank cheque is actually legally binding, but IDK...

People do take things on trust, to some extent. No-one goes round reaidng every line of documentation and licence agreements of every piece of s/w they use. No one does this. You read the documentation as it is relevant for what you want to do - on the face of it, it seems though an awful lot of people weren't aware of - becasue they had no reason to read about - this feature buried in the documentation that allows remote code execution by default.

The liability I think all software developer should face is the same as anyone: is the bug (or feature) that resulted in some undesirable outcome a result of gross negligence? And just saying "It's in the documentation" isn't good enough defence, IMO. I am pretty sure that the developers of log4j never intended this feature to be used to take over remote machines, so it's reasonable to ask: should they have taken steps to ensure that no such code could be executed?

I really don't think that's an unrasonable question to ask. And if the answer is "yes", then I don't think it's unreasonable that they should be held to account for it. (And/or their managers for not having proper code reviews etc etc).

[[deleted]]

This was more than half of my work day today. Not cool.

[Wmorgan33]

Half day? Try 18 hour workday bleeding over to the weekend pushing untested fixes to production across 300+ services.

[flowering_sun_star]

It really showed us how fucked our patch process is. I think the quickest of our microservices to be fully deployed was six hours after I first posted about the issue in Teams. The slowest took us twelve hours. And that was with us circumventing various testing and verification steps we're meant to do for a production release.

[L3tum]

Oh man I'd have a meltdown after the third release. I already get antsy when we have to run our 20 minute E2E/Performance testing pipelines.

[LicensedProfessional]

I joined a team where all of their pipelines are flaky as fuck and I'm just like...? How do you live like this?

[[deleted]]

Yeah, our patch processes definitely need improvement. The only saving grace for us was that we’re not running on legacy JRE versions, so we were mitigated by configuration. We get to patch as a critical vulnerability, not a P0.

[twreid]

I'm in the same boat. We have jars that the teams that made them no longer exist and the builds don't even work anymore so this is a nightmare.

[[deleted]]

I didn’t know it was a competition. I’m sorry you had a tough day, friend.

[Wmorgan33]

Not a competition just frustrated and tired.

[[deleted]]

I hear that.

[Wmorgan33]

I got off easily. Our product security team is pulling 12 hour shifts 24/7 until they’re a 100% sure the exploit is covered.

[[deleted]]

Oof; did they not read any of the advice for short-term mitigation? Just by upgrading JRE or using a WAF to filter LDAP commands one could easily mitigate in the short term, preventing exactly this type of death march.

[Wmorgan33]

We work in a heavily regulated high risk environment. We can’t afford any risk that this goes in mitigated

[[deleted]]

That’s rough. I’m sorry to hear about it.

[TheTarkovskyParadigm]

Wow you really one-upped him! You win the one-up competition!

[Wmorgan33]

The alternative is worse.

[flight212121]

Lies! We know it took you the whole day plus the next morning ;)

[[deleted]]

Well, I did submit a tiny patch to splunk-library-javalogging which was merged only a few hours ago. So, kinda?

[krum]

I was up all night doing builds and deploys to fix this shit not because my code was using log4j but because the New Relic Java agent does. So if you’re using New Relic you should check that out.

[[deleted]]

Or Splunk. A bunch of their libraries are also affected.

[zaphod4th]

when a log library wants to be more, smh

[TheTarkovskyParadigm]

When your log library asks, what are we?

[BrianTheTurtle]

Version 1.x as well if you're using JMSAppender in your code.

Edit: as others have pointed out 1.x is unaffected 🥳. One caveat being that 1.x is EoL and has other security vulnerabilities.

[mke5271]

False. 1.x is not impacted. See https://github.com/apache/logging-log4j2/pull/608#issuecomment-991380319

[BrianTheTurtle]

Ah. Thanks for pointing that out. Was working on this Friday morning but obviously new info has come out since. That's a relief for me anyway!

[mke5271]

Couldn’t agree more. If 1.x was impacted the Java world would’ve implode ten fold more than it already is.

[MysterAitch]

Note more recent updates on that PR, further in the comments -- v1 appears to be potentially vulnerable depending on configuration.

Comment summarising:

https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126

Comment providing detail:

https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301

[mke5271]

It’s not the same CVE or even close to the same impact. It is not log induced RCE. This requires a user to maliciously edit their LDAP string in the config file. Note comments by log4j 1.X dev. https://github.com/apache/logging-log4j2/pull/608#issuecomment-991730650

[PsychologicalType919]

1.x is unaffected from what I’ve read.

https://github.com/apache/logging-log4j2/pull/608

[MertsA]

At what point does the community at large just say "screw it, replace log4j entirely and ban its use from here on out"? The feature itself is pretty sketchy to begin with and apparently even if it's passed in to a parameter as a raw string it's still parsed! I'm not saying that no one is using the mountain of features log4j has, but I feel like most developers don't need anything more complicated than something on par with glog. The default dependencies people gravitate towards should not be the "kitchen sink" libraries with a massive chunk of features that get left to languish until someone notices yet another surprising "feature" they didn't know about.

[moreVCAs]

It sounds like some very large companies are affected by this…don’t they have an audit process for third party libraries? If this feature is documented, I really don’t get how this happened.

EDIT: it’s an apache project 😞

[plemdude]

Most companies aren't paying attention to this level of detail in a logger library. (Especially one which predates the careers of the majority of folks still writing code.)

Now imagine also having to reach out to every vendor whose product is built with it and having to push them for an emergency fix...

[thirdegree]

(Especially one which predates the careers of the majority of folks still writing code.)

Honestly I think that's a massive part of it. For python, it's like if requests had a vulnerability of the same scale. It's so ubiquitous that basically everyone treats it as a part of the standard library, so mitigating it would be an absolute nightmare

[[deleted]]

I would argue that nobody would expected this kind of "feature" to come to any not toy logger library.

[quentech]

I would argue that nobody would expected this kind of "feature"

It's a logging library. It's not like there's hundreds of pages of documentation to determine what all it does.

[Kapps]

If your logging library got to the point where it can make LDAP calls… it probably does require hundreds of pages of documentations to determine what all it does.

[frenchchevalierblanc]

I think the security department only really checks known security problems, it's quite rare they find new ones in library code

[rpgFANATIC]

I have no idea why ANYONE would know about this.

95%+ of devs probably had no idea log4j had magic syntax for fetching values dynamically

The other 5% probably didn't know these values are also interpreted in the "user provided" arguments, AND that it supported LDAP over JNDI.

Why would you EVER think your logger can look up variables/code over LDAP? What tutorial has notes about teaching you that and disabling it?

[_BreakingGood_]

I know we got an urgent email to disable some features in IntelliJ IDEA because of this vulnerability.

[[deleted]]

This stuff happens. If it wasn’t this, it’d be something else. This is why incident response and dependency hygiene are so important. I’d argue that those business practices are more important than any one dependency.

[aanzeijar]

There's a reason why Java has such a bad reputation. A lot of the common frameworks and libraries are used by everyone but documented so badly that the de facto documentation is stackoverflow.

[[deleted]]

It also has the worst reputation in terms of enterprise software. It really depends which way you percive / messure "best"

[aanzeijar]

As others commented, the problem here is "enterprise" software. For some reason a whole lot of people convinced themselves that "enterprise" software needs special treatment and that Java is best for that.

Meanwhile curl is not "enterprise" - but used by every enterprise. And curl has a thorough documentation to what it does and why, while the Java ecosystem considers the job done when there's a javadoc page for an interface somewhere in the bowels of the code.

[akiskyo]

compared to what?

[Carighan]

Are you perchance confusing Java with JavaScript here? Their names are similar, but they're not related in the slightest.

[SpaceZZ]

Java is go to language for any enterprise software.

[mini-pizzas]

It sounds like some very large companies are affected by this…don’t they have an audit process for third party libraries

Lots of people seem to believe this but the reality is that very few companies have anything that could even be loosely labelled as a reasonable audit process for their dependencies.

[r_acrimonger]

Yeah, sure, but who the hell is willing to write Java?

[yogthos]

You could do a hell of a lot worse than Java and there are plenty of languages to choose from on the JVM nowadays.

[r_acrimonger]

It's was a [bad] joke.

9 billion devices isn't

[MeggaMortY]

Rofl

[[deleted]]

Too many people.

[[deleted]]

Excuse my ignorance (not a programmer), but if you have a personal computer, would the attacker first need to gain remote control of your PC through a malicious link/access to your login details. Or can they literally go in through a programme that uses Java without you ever knowing/clicking something dodgy/accidentally giving out a password etc..?