Ghostcat Bug Impacts All Apache Tomcat Versions Released in the Last 13 Years (zdnet.com) 45
Apache Tomcat servers released in the last 13 years are vulnerable to a bug named Ghostcat that can allow hackers to take over unpatched systems. From a report: Discovered by Chinese cybersecurity firm Chaitin Tech, Ghostcat is a flaw in the Tomcat AJP protocol. AJP stands for Apache JServ Protocol and is a performance-optimized version of the HTTP protocol in binary format. Tomcat uses AJP to exchange data with nearby Apache HTTPD web servers or other Tomcat instances. Tomcat's AJP connector is enabled by default on all Tomcat servers and listens on the server's port 8009. Chaitin researchers say they discovered a bug in AJP that can be exploited to either read or write files to a Tomcat server.
No software without bugs... (Score:1)
Re: (Score:2)
Are you saying that a bug that allows unintended/unauthorised reading and writing of files on the server via HTTP doesn't count as a security risk?
Re: (Score:2)
Tomcat isn't super widely used.
Really??? I thought Tomcat was the leading application server out there. What has taken its place?
Re: (Score:2)
In what alternate reality is Tomcat not super widely used? What’s a more popular application server?
Re: (Score:2)
It's not actually a bug, it's a feature.
The only problem is with people who open port 8009 for public access. They get what they deserve, IMHO.
Re: No software without bugs... (Score:1)
Re: No software without bugs... (Score:1)
Re: (Score:1)
If you cannot read anything into my comment it means i was nit [emphasis mine] clear or you are clearly not understand what i am saying. I am sorry for that.
Was this intentional? Or am I nitpicking?
Re: No software without bugs... (Score:1)
Re: (Score:2)
I think it is safe to asume that every piece of software contains bugs. Not all bugs are security risks and not all security risks are related to bugs.
Most security risks are related to bad design.
I agree. And bad implementation. All security critical functionality should be designed and implemented with redundancies that prevent single bugs (or multiple bugs on very critical things) from breaking security. This approach is just part of sound engineering practices of having redundancies and quite standard in established engineering fields. Unfortunately, software engineering is not really an established engineering field yet, and still has far too many non-engineers (that have no real clue what they
... and then there is Tomcat (Score:2)
Almost all software has bugs, amd then there's Tomcat, which is nothing but a pile of security bugs. I used to maintain a security exposure database. Tomcat has far more than its share of significant issues.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Tomcat is a god damned fortress compared to anything built with PHP.
Until 2005 (Score:2)
PHP was really bad from 1994-2005.
The team had an attitude change in 2005. That's now 15 years ago.
Re: (Score:2)
The existing "problem" with PHP has a few layers -
First, there is a low barrier to entry. ionos.com/1and1.com can host you for a buck a month and give you a lamp stack. This means that it is quick and easy for inexperienced folks learning to code to start using it.
Next,is that the search engines never forget and don't typically detract ranking from older content even with plenty of similar newer content. This means that when one of those new coders does a google/bing/duckduckgo/whatever search for "conne
More specifically, the Tomcat - Struts stack (Score:3)
I actually should have been more specific. While Tomcat itself has had several major vulnerabilities, it's most often used with Struts, and Struts is awful. The typical Struts-Tomcat stack will give me remote code execution pretty much every time.
Re: (Score:1)
Conclusion (Score:2)
So there is a ghost in the machine...
Blocked by NAT and ordinary firewall setups (Score:3)
I do note that people who insist that all hosts should be accessible inside of a network, and all devices should be exposed to the world as part of the Internet of Things, have environments that are very vulnerable to this sort of attack. Other personnel inside their networks may not even realize that they're running Tomcat, or that the attached storage device or firewall itself runse Tomcat, may not realize they're relying on Jetty or any of a dozen other web servers as part of their default setups, and they do not cooperate in implementing robust firewall rules that might help reduce the exposed vulnerability.
It's a reason that one of my elementary security steps is segmenting web traffic. An internal network should be able to _reach_ port 8009 outbound, nor vice versa.
Less severe than I thought (Score:2)
Re: (Score:1)
Re: (Score:2)
15 years ago when I worked with Tomcat, it was fairly well known that you either disable AJP if you are using the internal webserver, set it to listen on localhost if you are using an Apache or these days probably Nginx or lighttpd frontend on the same machine, or have the whole machine firewalled off if you have a large scale deployment that needs the frontend on a different machine.
Never deploy default configurations in production. Production configurations should always have a security review. That sai
Re: (Score:1)
Re: (Score:2)
I don't know about that... if you're using AJP connections in Tomcat, you're probably only using it to connect to Apache. As long as you're only exposing port 443 to the network, Tomcat shouldn't really be exposed externally.
Re: (Score:3)
I'd be willing to bet it's open on most setups though. In fact, every customer I ever knew that insisted on running Tomcat opened up that port. I know, you're going to say something like, "there isn't any good reason to", but most web developers I had the pleasure to work with wanted all the ports open so that they could connect from their IPs in India, and whitelisting IPs was never an option because "our IPs change all the time, please just do the needful". The needful also meant opening port 3306 for MySQL. To the world.
tl;dr - Web developers are mostly idiots.
This is why you have a development server and a production server - so you can put the idiots on the dev server.
Re: Less severe than I thought (Score:1)
Re: Less severe than I thought (Score:2)
For example, I gave an interview candidate a question about a hypothetical security breach on a public facing site with non-critical marketing data. Scenario included that the CEO was talking to VC in the morning and it had to be back up by 8am or w
Re: (Score:3)
Any time I've needed to connect directly to a port that is blocked off by firewall for dev stuff (ie, run MySQL Workbench locally but talk to a mysqld on localhost:3306 on the remote machine) I've simply used a SSH tunnel and forwarded the needed ports.
Heck instead of installing work's VPN software (not open source, warned me about wanting to replace my SSL libs with their own copies, etc) I simply tunnel a port for RDP, one for the Liberty webserver running on my work desktop for local dev, and a -D option
Re: (Score:2)
tl;dr - Web developers are mostly idiots.
And not the Western sysadmins who fail to set up a VPN in the face of such requests. Sure...
Re: (Score:2)
tl;dr - Web developers are mostly idiots.
and
from their IPs in India
Ah see there's the problem. There's good programmers in India, however most of them work for someone already. So the left over programmers either fall into "have potential" or "stay as far away from as possible". Any "programmer" that requests open all the ports, especially the one's from India, fall firmly into the latter group.
except (Score:2)
Feature not a bug (Score:5, Informative)
This is a feature of Tomcat and it is working as expect, the issue here is the same kind of problem as leaving a default admin password in place. i.e. No competent deployment engineer would make this port 8009 active by mistake.
https://tomcat.apache.org/tomc... [apache.org]
Re: (Score:3)
On the other hand, if I see a developer working with Tomcat at Starbucks, I might try to connect to their Tomcat.
Re: (Score:2)
Unfortunately many IoT developers are great at writing software to make their hardware do things, but expecting them to also be experts in web site management, network management and security is stupid. My understanding is that Tomcat's memory footprint is small enough that it's popular on memory-limited devices, so it's probably deployed incorrectly on a gazillion field moisture monitors, sewer monitoring equipment, security cameras, alarm panels, etc.