Hacker News Reader

Comment by jojohohanon | Hacker News Reader

There’s room for both sides of the razor. The heapdumpz could be there maliciously, but incompetently made globally accessible.

View on HN

From the Wired article: "The archive server is programmed in Java and is built using Spring Boot, an open source framework for creating Java applications. Spring Boot includes a set of features called Actuator that helps developers monitor and debug their applications. One of these features is the heap dump endpoint,"

So the heapdumps being available is a Spring Boot feature so it does not appear to be malicious.

I'm the original author of the Spring Boot feature for heapdumps: https://github.com/spring-projects/spring-boot/pull/5670.

It seems that users commonly misconfigure Spring Boot security or ignore it completely. To improve the situation, I made this PR: https://github.com/spring-projects/spring-boot/pull/45624.

When the PR was created in 2016, endpoints were marked as "sensitive" and, for example, the heapdump endpoint would have to be explicitly enabled. However, Spring Boot has evolved over the years, and only the "shutdown" endpoint was made "restricted" in the later solutions. My recent PR will address that weakness in Spring Boot when users misconfigure or ignore security for a Spring Boot app so that heapdumps won't get exposed by default.

I don't get why 2+ years after Log4J we are still dealing with this from Java libraries developers.

Your end users are not security savvy, they will never be security savvy and you need to protect them from themselves instead of handing them loaded handgun. This language more than most is filled with people punching buttons for paycheck.

- Signed, Angry SRE who gets to deal with this crap.

In my opinion, the original sin of Spring Boot Actuator is allowing server.port and management.server.port to be the same. It makes it too convenient for developers to skip the security review that would be done for opening a non-standard port.

I think it would be wise to either disallow the ports being the same, or if they are the same, only enable the health endpoint.

I'm more of the opinion that developers will make smart choices, when motivated.

Sure, punching buttons for money is a widespread issue in the industry, but devs also like convenience.

Security has the hard problem that it's infuriatingly difficult to troubleshoot (ever tried to write security policies for an app or figure out how to let an app through a firewall, or set of firewalls?), and there's a bit of a culture of "security by obscurity".

So it's kind of expected that this is the behavior...

Sure some people will really just not care, mistakes will be made, but secure defaults, easy to configure and simple to understand are features not often seen from security products generally. This is driven by poor motivations from security folk who want to protect their industry...

This feature must be explicitly enabled, it is not on by default nor by accident.

huh, I sure seem to be needing to debug this a lot, I guess I'll just leave it turned on all the time that way I can say a few seconds next time. Larry Wall says one of the virtues of being a great developer is laziness!

Based on [1] it seems like one `management.endpoints.web.exposure.include=*` is enough to expose everything including the heapdump endpoint on the public HTTP API without authentication. It's even there in the docs as an example.

Looks like there is a change [2] coming to the `management.endpoint.heapdump.access` default value that would make this harder to expose by accident.

Let's look for `env` next...

[1] https://docs.spring.io/spring-boot/reference/actuator/endpoi...

[2] https://github.com/spring-projects/spring-boot/pull/45624

Reply on news.ycombinator.com