Wallbleed, a buffer over-read vulnerability that existed in the DNS injection subsystem of the Great Firewall of China. Wallbleed caused certain nation-wide censorship middleboxes to reveal up to 125 bytes of their memory when censoring a crafted DNS query. It afforded a rare insight into one of the Great Firewall’s well-known network attacks, namely DNS injection, in terms of its internal architecture and the censor’s operational behaviors.
I'm no lawyer, but I seem to recall that a contract that allows one side to unilaterally withdraw for unspecified reasons is not a real contract (the legal term is "illusory promise" or "illusory contract").
Cloudflare apparently has a legal team, so I have to assume they know whether their terms of service are actually an enforceable contract, but that provision sounds fishy to me.
The point here is that if you have an account with Cloudflare, but Cloudflare's terms of use allow it to cancel your account for any reason--which is how I understand the CEO's explanation, regardless of whether I think the stated reason is good or bad--then you may be relying on something that you shouldn't rely on.
> I seem to recall that a contract that allows one side to unilaterally withdraw for unspecified reasons is not a real contract
I certainly hope you're wrong. Because I've "unilaterally withdrawn from" (i. e. "canceled") literally hundreds of contracts, and I don't remember ever giving a reason.
If Cloudflare can cancel the contract at the CEO's whim without needing to prove that the customer has somehow violated some terms of use, then Cloudflare isn't "bound to perform" using Cornell's terminology.
In ordinary contracts that's true, but this case is different because it's more of a continuing contract
It is not a one time performance like washing a car or shoveling a driveway or buying grocheries. It is a continual term contract where each party agrees to continue going. In these cases, it would be legal to have a clause allowing either party to terminate the contract at any time. Certainly daily stormer was free to stop using cloud flare at any time. And similarly, cloudflare is free to terminate the stormer's account at any time provided they refund the cash. So the contract is not really illusory because both parties still have the obligation to perform, they just don't have the obligation to continue performing.
macOS and iOS don't support OpenVPN with the built-in client. You can use strongSwan-based VPNs (e.g., as would be deployed through Algo) or Cisco, but for OpenVPN you'll need a custom client which, unfortunately, very likely brings along its own .kext.
TunnelBlick comes with a tun/tap kext that is signed. This is not required on systems where Apple already has tun/tap support compiled in (not sure when that started, but it's been a long time)
From the known issues page:
"If you are running on OS X 10.6.8 or higher and using OpenVPN 2.3.4 or higher and using a TUN device, the default Tunnelblick setting to "Load Tun Automatically" (on the "Advanced" settings window) will avoid this problem by not loading the tun kext — OS X's built-in "utun" device will be used instead of a "tun" device."
Is a .kext actually required for a vpn client? My understanding is that TunnelBlick just creates a tun network in user-space. Why would it need to be in the kernel?
I think you may be confusing deterministic reproducible
builds (that remove randomness and ensure binaries
have the same content hash regardless of who builds
them (so you can reproduce what the maintainers did
and verify the source and binaries) to merely a repro'd
environment where everything still works because deps
are included, which seems to be all that Nix promises
(and in fact there is at least one open issue to add full
deterministic builds to Nix
https://github.com/NixOS/nixpkgs/issues/9731 )
Any comparatively large corporation very likely has a release process for these sorts of things where a bunch of groups (like PR, maybe Legal etc) would take a look. Releasing company IP as open source outside of such a process would be a gross violation of any number of non-disclosure agreements between employer and employee.
There's nothing in the OPs post suggesting SSH was exposed to the public, or that the breach happened over SSH. So it's important to secure that, but it's also important to think holistically about the attack surface.
You assume the breach happened over SSH. This is valuable information to securing SSH, but it's entirely possible the original breach happened over some other service, and there were some other steps involved in the breach before the SSH screenshot was taken.
True but I'm working from the angle that If the breach happened via some other means then they'd need some way to remotely execute code to enable SSH, create valid login credentials, and disable the firewall; in which case they already have a more convenient shell access so gaining access to SSH becomes redundant.
However it's possible that the attacker's screenshot was of a remote shell initiated via some other means and the OP assumed it was via SSH.
Edit: why was this downvoted? If there's an error then I need to be educated. I've spent enough years of my professional life hardening servers to have some idea what I'm talking about, but I'd be an idiot if I didn't listen to the expertise of others. So please correct me rather than downvote me :)
Best not to ask why downvoted. Those people's responses will rarely teach you anything. The kind that would will usually reply instead of downvote. Plus, a few already explained to me it's common for a post to get hit with a few negative votes followed by corrective action as other, open-minded people show up. Happens all the time with mine.
The article makes no mention of TLS anywhere, and the example endpoints are all HTTP. So, this is a thoroughly insecure implementation, relying on very weak security mechanisms, prone to straightforward interception and tampering, replay etc.
