terom

https://x.com/telegram/status/2038069726316834994 Telegram claims that exploitation of the vulnerability is blocked by server-side validation of stickers

I haven't seen a serialization exception, but I have run into plenty of footguns with YAML (ref GitHub Actions).

The DSL semantics can be weird with when things like params/env expansions in options block are evaluated.

Working with Jenkins CasC, JobDSL and declarative pipelines, I'm not sure where the million times comes from. Sure, there are some annoying parts, and GHA has the social network for reusable actions, but apart from that it's not that different.

Oldschool maven type jobs where you type shell script into a `<textarea>`? Yeah, let's not talk about those, but we don't have a single one left anymore.

downdetectorsdowndetector.com does not load the results as part of the HTML, nor does it do any API requests to retrieve the status. Instead, the obfuscated javascript code contains a `generateMockStatus()` function that has parts like `responseTimeMs: randomInt(...)` and a hardcoded `status: up` / `httpStatus: 200`. I didn't reverse-engineer the entire script, but based on it incorrectly showing downdetector.com as being up today, I'm pretty sure that downdetectorsdowndetector.com is just faking the results.

downdetectorsdowndetectorsdowndetector.com and downdetectorsdowndetectorsdowndetectorsdowndetector.com seem like they might be legit. One has the results in the HTML, the other fetches some JSON from a backend (`status4.php`).

re-search :D

Also with additional control difficulty due to reduced hydraulic pressure.

On the Boeing 767, the control surfaces are so large that the pilots cannot move them with muscle power alone. Instead, hydraulic systems are used to multiply the forces applied by the pilots. Since the engines supply power for the hydraulic systems, in the case of a complete power outage, the aircraft was designed with a ram air turbine that swings out from a compartment located beneath the bottom of the 767,[10] and drives a hydraulic pump to supply power to hydraulic systems.

As the aircraft slowed on approach to landing, the reduced power generated by the ram air turbine rendered the aircraft increasingly difficult to control.[16]

The forward slip disrupted airflow past the ram air turbine, which decreased the hydraulic power available; the pilots were surprised to find the aircraft slow to respond when straightening after the forward slip.

From the Cloudflare incident:

Cloudflare’s critical Workers KV service went offline due to an outage of a 3rd party service that is a key dependency. As a result, certain Cloudflare products that rely on KV service to store and disseminate information are unavailable [...]

Surprising, but not entirely unplausible for a GCP outage to spread to CF.

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

Going a bit further, it seems like there's a grain of truth here, HTTP/2 has a stream priority dependency mechanism [1] and this report [2] from Imperva describes an actual Dependency Cycle DoS in the nghttp implementation.

Unfortunately that's where it seems to end... I'm not that familiar with QUIC and HTTP/2, but I think the closest it gets is that the GitHub repo exists and has a `class QuicConnection` [3]. Beyond that, the QUIC protocol layer doesn't have any concept of exchanging stream priorities [4] and HTTP/2 priorities are something the client sends, not the server? The PoC also mentions HTTP/3 and PRIORITY_UPDATE frames, but those are from the newer RFC 9218 [5] and lack the stream dependencies used in HTTP/2 PRIORITY frames.

I should learn more about HTTP/3!

[1] https://blog.cloudflare.com/adopting-a-new-approach-to-http-...

[2] https://www.imperva.com/docs/imperva_hii_http2.pdf

[3] https://github.com/aiortc/aioquic/blob/218f940467cf25d364890...

[4] https://datatracker.ietf.org/doc/html/rfc9000#name-stream-pr...

[5] https://www.rfc-editor.org/rfc/rfc9218.html#name-the-priorit...

The git commit hashes in the diff are interesting: 1a2b3c4..d4e5f6a

I think my wetware pattern-matching brain spots a pattern there.

Portugal has an even bigger relative drop in load, from 5852MW at 11:00 hours -> 613MW at 13:00 hours - these seem like 1 hour averages.

[1] https://transparency.entsoe.eu/load-domain/r2/totalLoadR2/sh...

That graph doesn't seem to make a very clear distinction between historical, real-time and predicted values... I think the event happened at 12:30 local time or so.

There seems to be some kind of recurrent daily pattern where the French - Spanish interconnect switches from Spain -> France imports to France -> Spain exports at around that time, and then back again in the late afternoon.

It looks like the Iberian peninsula is relatively isolated from the rest of the CESA synchronous grid, with only 2% cross-border capacity compared to local generation. [1]

There's a map at [2]

The Spanish electricity system is currently connected to the systems of France, Portugal, Andorra and Morocco. The exchange capacity of this interconnection is around 3 GW, which represents a low level of interconnection for the peninsula. The international interconnection level is calculated by comparing the electricity exchange capacity with other countries with the generation capacity or installed power.

[1] https://www.ree.es/en/ecological-transition/electricity-inte...

[2] https://www.entsoe.eu/data/map/

https://news.ycombinator.com/item?id=43486945 related

Yeah, you have to move it off-planet to achieve an actual security boundary.

In our threat model the upper bound on the useful lifetime of the system is limited by the light-distance time from the nearest adversary.

Yeah, and that makes sense in the context of an acceptable use policy for Mozilla services that are not your use of the Firefox browser.

But the same AUP for the services is now explicitly referenced in the TOS for the browser. How are you supposed to read it - the AUP only applies to your use of the browser to access the services? Isn't that already implicit if you're using the services? Surely it can't be attempting to apply the services AUP to any non-service use of the browser?

Very confusing, it seems badly written to me.

Same thing with the "Some Services in Firefox Require a Mozilla Account" and then the "Termination" with a notification to the (optional) account. Somewhat disconcerting.

[1] Mozilla can suspend or end anyone’s access to Firefox at any time for any reason, including if Mozilla decides not to offer Firefox anymore. If we decide to suspend or end your access, we will try to notify you at the email address associated with your account or the next time you attempt to access your account.

[1] https://www.mozilla.org/en-US/about/legal/terms/firefox/#moz...

Wait, Mozilla is banning the use of their Firefox browser for porn? That's going to hurt adoption.

What's with the mixup of their browser and services policies?

[1] Your use of Firefox must follow Mozilla’s Acceptable Use Policy, and you agree that you will not use Firefox to infringe anyone’s rights or violate any applicable laws or regulations.

[2] You may not use any of Mozilla’s services to:

* Upload, download, transmit, display, or grant access to content that includes graphic depictions of sexuality or violence,

[1] https://www.mozilla.org/en-US/about/legal/terms/firefox/#you... [2] https://www.mozilla.org/en-US/about/legal/acceptable-use/

It's fascinating that we've built a system that has expended perhaps several million dollars of engineering, legal and admin etc time over the issue of a single letter not being capitalized [1], without any demonstrable impact beyond a failure to meet ambiguous specifications.

I do hope that dealing with all of the underlying issues around revocation etc makes the time and effort spent useful, and the Web PKI doesn't just mire itself in squabbling that blocks progress on actually meaningful issues.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1894560

These are technically kinda crazy, because they use a normal schuko plug (with male pins) to output power. It allows loading the circuit with a higher total ampacity than the circuit breaker protecting the wiring at the distribution panel. It takes a very specific set of regulations to make these legal, and those don't apply elsewhere in Europe.

https://www.vde.com/de/fnn/themen/tar/tar-niederspannung/erz...

https://tukes.fi/-/ala-kayta-pistorasiaan-kytkettavaa-aurink... Finnish national authority says: NO

Renewing the certificates seems technically pointless, but some organizations/federations require it.

Rotating the keys would make some sense, but just swapping the cert for a new one issued against the same keys doesn't. It's the easiest way to fulfill those requirements, because you don't need to synchronize the metadata updates, the signatures are always valid with both the old and new cert.

The title seems incorrect, per Comment#10 https://bugzilla.mozilla.org/show_bug.cgi?id=1877388#c10 all missued certificates were eventually revoked

2024-01-22 08:25 The error message “ERROR: basicConstraints MAY appear in the certificate, and when it is included MUST be marked as critical “ in crt.sh was found in our weekly checks

2024-02-05 13:00 Videoconference with the management of the Trust Center with the decision, to revoke all certificates that have not yet been revoked the next day 13:25 Information to customers about the final revocation of all certificates the next day

2024-06-02 15:41 All affected certificates are replaced and revoked.

Given the comment was posted 2024-02-09, the last date is probably a typo of 2024-02-06, aka within 16 days.

https://old.reddit.com/r/crowdstrike/comments/1e6vmkf/bsod_e... quotes the CrowdStrike advisory verbatim, which has timestamps of 04:09 UTC for the problematic version and 05:27 for the reverted (good) version.

"post-processing step" aka regex? :)

HN comments from a green username citing a friend who knows someone aren't the greatest source, but this sounds so believeable

https://azure.status.microsoft/en-us/status/history/ doesn't seem to have links to the individual incidents. Some reports claim the Azure / Microsoft 365 outages were related to crowdstrike, but this sounds like an entirely separate incident.

AFAIK the broken crowdstrike channel update happened at 2024-07-19 06:05 UTC and was "fixed" (rolled back) at 06:47 UTC, but I don't have a proper source for that timeline?

EDIT: https://azure.status.microsoft/en-gb/status claims 2024-07-18 19:00 UTC as the approximate start of impact for the crowdstrike update. It would be nice to find a proper source for the start and mitigation timelines...

EDIT: reddit threads reporting symptoms start at approx 2024-07-19 05:00 UTC. That would mean the crowdstrike impact started soon after the azure recovery.

---

What happened?

Between 21:56 UTC on 18 July 2024 and 12:15 UTC on 19 July 2024, customers may have experienced issues with multiple Azure services in the Central US region including failures with service management operations and connectivity or availability of services. A storage incident impacted the availability of Virtual Machines which may have also restarted unexpectedly. Services with dependencies on the impacted virtual machines and storage resources would have experienced impact.

What do we know so far?

We determined that a backend cluster management workflow deployed a configuration change causing backend access to be blocked between a subset of Azure Storage clusters and compute resources in the Central US region. This resulted in the compute resources automatically restarting when connectivity was lost to virtual disks hosted on impacted storage resources.

How did we respond?

21:56 UTC on 18 July 2024 – Customer impact began

22:13 UTC on 18 July 2024 – Storage team started investigating

22:41 UTC on 18 July 2024 – Additional Teams engaged to assist investigations

23:27 UTC on 18 July 2024 – All deployments in Central US stopped

23:35 UTC on 18 July 2024 – All deployments paused for all regions

00:45 UTC on 18 July 2024 – A configuration change as the underlying cause was confirmed

01:10 UTC on 19 July 2024 – Mitigation started

01:30 UTC on 19 July 2024 – Customers started seeing signs of recovery

02:51 UTC on 19 July 2024 – 99% of all impacted compute resources recovered

03:23 UTC on 19 July 2024 – All Azure Storage clusters confirmed recovery

03:41 UTC on 19 July 2024 – Mitigation confirmed for compute resources

Between 03:41 and 12:15 UTC on 19 July 2024 – Services which were impacted by this outage recovered progressively and engineers from the respective teams intervened where further manual recovery was needed. Following an extended monitoring period, we determined that impacted services had returned to their expected availability levels.

Reboot harder.

Update as of 10:30 UTC on 19 July 2024: We have received reports of successful recovery from some customers attempting multiple Virtual Machine restart operations on affected Virtual Machines.

We've received feedback from customers that several reboots (as many as 15 have been reported) may be required, but overall feedback is that reboots are an effective troubleshooting step at this stage.

https://status.cloud.microsoft/

I don't think DNSSEC would help in the common case of non-validating stub resolvers querying a public resolver. My understanding is that the DNS query response from a DNSSEC-validating public recursive resolver doesn't contain the information required for the stub client to validate it, only a single AD bit.

https://a.aliexpress.com/_EzMRNIv €250 for one axis (edge) and €500 for a 3-axis (single point). There are a couple sellers / designs.

It will take a bit more engineering than some optimistic sign-flipping to bring it down to $50 retail (~$10 BOM).

In my case, the BOM was close to €2500, so be prepared for that.

EDIT: someone pointed out that there are actually some designs available on AliExpress, e.g. https://a.aliexpress.com/_EzMRNIv €250 for one axis (edge) and €500 for a 3-axis (single point).

https://www.mouser.fi/ProductDetail/Diodes-Incorporated/PT8A...

Now I want to buy a couple... 0.856 € unit price for 1pcs, available in stock.

New evil plan: corner the market on toaster controller ICs and build up a strategic reserve to resell to manufacturers at inflated prices.

https://photos.app.goo.gl/S6sFaEUxY89Tgxn56 here's an example of the safety/certification markings from a 24V power supply sold in the EU.

Take a close look at the TÜV/GS logo and font. I seriously doubt the UL file number E131992 exists. The Safety Mark 021068-00 code is for a Samsung AC Adapter [1], which this is not. You can see some of the same details in the AliExpress listings.

[1] https://www.go.gov.sg/safety-mark