Live data from Hacker News

US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

zdnet.com

311–320 of 344 posts

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#311
post #281

Earlier quoted context omitted.

First you need a fire starter, which in this case must be made out of bills valued 100 USD each or greater. It'll take quite a few to light the Datacenter licenses that are the now the only on-prem tier on fire...

So... you do not, in fact, have an answer to the question?

Lacking humor I see.

My point is that it is experience acquired from managing these for a decade. If you wish to acquire this experience you need to run it, which is now even costlier than it used to be.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#312

Earlier quoted context omitted.

> If O365 looses mails and these mails do not show up in message tracing either (i.e., not classified as spam), we would probably have heard about that by now. Internet email has never been considered a highly-reliable messaging system; its quite possible an infrequent data loss in a mail server would get misattributed to a failure outside. Heck, even ignoring the unreliability of email generally, in fact, your assum…

I would beg to differ about email reliability, also see https://datatracker.ietf.org/doc/html/rfc5321#section-6.1 but do agree that everything could get lost for some reason. But that is not the main point. Even if the email was lost somewhere in Office 365, people were already pointing out to Atlassian that they should really send a follow up on Aug 27: https://jira.atlassian.com/browse/CONFSERVER-67940?focusedCo...

The follow-up-request was to notify users that the advisory has been updated, not to ensure that customers received the Aug 25 email which linked to that advisory.

Either is was Atlassian's mailing list software which did not attempt to re-send the email to you after it noticed that the connection got dropped (should that have happened), or is was Microsoft which dropped the email after receiving it, but before storing it into the database and assigning it to your account.

You cannot know who is responsible for this delivery error unless you ask them directly.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#314

Earlier quoted context omitted.

However, one does not conclude from the other as is insinuated in the comment.

If all products have CVEs, and CVEs are a form of defect, then it follows quite naturally that highly defective products will have CVEs, likely more than less defective products. So yes. Yes it does. Unless you meant that CVEs imply garbage code, in which case I think you read the comment wrong.

But here we're talking about one particular CVE:

> everyone is now aware of the awful engineering practices that underpin their products

This one fault doesn't tell anything about overall quality of the product.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#315

Earlier quoted context omitted.

If all products have CVEs, and CVEs are a form of defect, then it follows quite naturally that highly defective products will have CVEs, likely more than less defective products. So yes. Yes it does. Unless you meant that CVEs imply garbage code, in which case I think you read the comment wrong.

But here we're talking about one particular CVE: > everyone is now aware of the awful engineering practices that underpin their products This one fault doesn't tell anything about overall quality of the product.

This is a complete misunderstanding caused by not readinf the first half of the first sentence of the comment.

The full sentence:

> The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products.

I.e., because the software is available for on-prem deployment, we have experience deploying, managing and debugging it, and therefore know that it is garbage, and we can apply this knowledge to conclude that their cloud offering is garbage.

It does not say the product is garbage because of a CVE.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#316

Earlier quoted context omitted.

If all products have CVEs, and CVEs are a form of defect, then it follows quite naturally that highly defective products will have CVEs, likely more than less defective products. So yes. Yes it does. Unless you meant that CVEs imply garbage code, in which case I think you read the comment wrong.

It follows in theory but may not in practice. Certain software may have lots of defects that are not CVEs.

All products will have defects that are not CVEs, hopefully by a large margin.

But every sufficiently complicated product will have defects of this type, and a higher probability of defects does increase the probability of CVEs.

So, it follows in practice, as can be seen by looking at CVE rates from projects with high defect rates (web browsers, kernels, ...) vs projects with low defect rate.

Note that defect rate differences can be caused by multiple things.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#317

Earlier quoted context omitted.

> "Just embed a confluence page into a task" Except that confluence and JIRA are both so slow that you'll still be there 2 minutes later waiting for it to load. Perhaps not everybody's experience is so bad? I don't understand how anyone could consider these products convenient given how ridiculously slow they were. We used to do refinement meetings over video call (I guess everyone is these days) inputting into JIRA,…

We use the cloud version, I've edited huge Confluence pages and it's typically very snappy. Jira likewise. Could be an under-resourced on-premise deployment?

I use the cloud version also. While Jira doesn't have any issues, editing Confluence pages can be a right pain. It is constantly "losing my connection" and prevents editing until it's happy again. There's no connection issues present, unless they're at Atlassian's end.

Watching the network tab, all I see is a requests to `bayeux-sync1` endpoint that take 5 seconds or longer. There's always one of these requests hung when it enters this unresponsive mode. I suspect this is some part of the syncing system for multiple editors. Which, if true, makes it particularly hilarious to me that the entire point of this system would be to sync multiple edits, yet it won't let me keep editing while it's waiting...

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#318
post #72

The good thing about the fact that Atlassian offers both on-prem and cloud versions of their offerings is, everyone is now aware of the awful engineering practices that underpin their products. We have to assume that there are problems of a similar nature in their cloud service, which is way more of a problem considering the number of orgs that depend on the JIRA SaaS offering. Maybe the founders could have used some…

Haha, atlassian will not go away. Since it’s not being sold to most people actually using it.

They just sell their feature list to CEO’s and Product Manager/Scrum Lords, and suddenly Atlassian is an absolute requirement.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#319

Earlier quoted context omitted.

You are missing the point entirely. Any sufficiently complicated product will eventually have major CVEs, as you say. Anyone having hosted Atlassians product know that these products are nothing but garbage fires on the inside, as the commenter above said. Both of these statements are true and not mutually exclusive in any way.

Where may I learn more about exactly how they are "garbage fires on the inside"? Thanks

Atlaskit (their UI framework) is open source.

It is very enlightening. Try using their editor component to display the text of one of your Jira comments and making it display attachments.

Re: US Cybercom says mass exploitation of Atlassian Confluence vulnerability ongoing

#320

Earlier quoted context omitted.

Atlassian has a reputation for poor engineering/backend practices. It's a great (to use) product though.

It's an ok product until you run into performance issues. Which due to said horrible backend engineering is numerous. Also their support is awful.

Don’t worry, the datacenter edition takes only 200ms to load their HTML, and then another 15s to generate their JS package on every single page load.
Post reply on HN