A large proportion of LPE vulnerabilities are in the nature of "perform a syscall to pass specially crafted data to the kernel and trigger a kernel bug". For containers, the kernel is the host kernel and now the host is compromised. For VMs, the kernel is the guest kernel and now the guest is compromised, but not the host. That's a much narrower compromise and in security models where root on the guest is already expected to be attacker-controlled, isn't even a vulnerability.
VM sandbox escape is just "perform a hypercall/trap to pass specially crafted data to the hypervisor and trigger a hypervisor bug". For virtual machines, the hypervisor is the privileged host and now the host is compromised.
There is no inherent advantage to virtualization, the only thing that matters is the security and robustness of the privileged host.
The only reason there is any advantage in common use is that the Linux Kernel is a security abomination designed for default-shared/allow services that people are now trying to kludge into providing multiplexed services. But even that advantage is minor in comparison to modern, commonplace threat actors who can spend millions to tens of millions of dollars finding security vulnerabilities in core functions and services.
You need privileged manager code that a highly skilled team of 10 with 3 years to pound on it can not find any vulnerabilities in to reach the minimum bar to be secure against prevailing threat actors, let alone near-future threat actors.
The syscall interface has a lot more attack surface than the hypercall interface. If you want to run existing applications, you have to implement the existing syscall interface.
The advantage to virtualization is that the syscall interface is being implemented by the guest kernel at a lower privilege level instead of the host kernel at a higher privilege level.
If this were true, it would be easy to support the claim with evidence. What were the last three Linux LPEs that could be used in a realistic scenario (an attacker with shell, root, full control of guest kernel) to compromise a KVM host? There are dozens of published LPEs every year, so this should be easy for you.
You know that is a nonsensical request. Why would a Linux LPE result in a guest to host escape?
That is like asking for the last 3 iMessage RCEs that that could be directly used to get a kernel compromise. You obviously leverage the RCE to get code execution in the unprivileged context then chain it with a LPE or unprivileged to privileged kernel escape. The RCE is very likely to be unrelated to the LPE and can likely even be mixed and matched if the RCE is good enough. You could do both simultaneously, and I guess some might exist, but that is just generally a poor, much harder strategy.
In this case the Linux Kernel LPE would only get you code execution in the unprivileged guest which you then need to chain with a unprivileged to privileged hypervisor escape.
Are you claiming that hypervisors or VMM systems are unhackable? That is a extraordinary claim that demands extraordinary evidence. Otherwise you agree there are VM escapes that can be chained with code execution in the guest which is my entire point.
Your security depends on the quality of your isolation boundary and there is no reason to believe the same class of people who gave us the awful security of the Linux Kernel are going to turn around and solve the same problem they failed to solve by calling it a hypervisor.
Is it possible we're just talking past each other? I read you to be claiming that guest->host escapes were straightforward in the Linux kernel security model (they are not). If we just agree, then we agree, and we should just chalk this up to message board ambiguity.
One is, suppose there are a thousand search engine bots. Then what you want is some standard facility to say "please give me a list of every resources on this site that has changed since <timestamp>" so they can each get a diff from the last time they crawled your site. Uploading each resource on the site to each of a thousand bots once is going to be irrelevant to a site serving millions of users (because it's a trivial percentage) and to a site with a small amount of content (because it's a small absolute number), which together constitute the vast majority of all sites.
The other is, there are aggressive bots that will try to scrape your entire site five times a day even if nothing has changed and ignore robots.txt. But then you set traps like disallowing something in robots.txt and then ban anything that tries to access it, which doesn't affect legitimate search engine crawlers because they respect robots.txt.
> then you set traps like disallowing something in robots.txt and then ban anything that tries to access it
That doesn't work at all when the scraper rapidly rotates IPs from different ASNs because you can't differentiate the legitimate from the abusive traffic on a per-request basis. All you can be certain of is that a significant portion of your traffic is abusive.
That results in aggressive filtering schemes which in turn means permitted bots must be whitelisted on a case by case basis.
> That doesn't work at all when the scraper rapidly rotates IPs from different ASNs because you can't differentiate the legitimate from the abusive traffic on a per-request basis.
Well sure you can. If it's requesting something which is allowed in robots.txt, it's a legitimate request. It's only if it's requesting something that isn't that you have to start trying to decide whether to filter it or not.
What does it matter if they use multiple IP addresses to request only things you would have allowed them to request from a single one?
> If it's requesting something which is allowed in robots.txt, it's a legitimate request.
An abusive scraper is pushing over your boxes. It is intentionally circumventing rate limits and (more generally) accurate attribution of the traffic source. In this example you have deemed such behavior to be abusive and would like to put a stop to it.
Any given request looks pretty much normal. The vast majority are coming from residential IPs (in this example your site serves mostly residential customers to begin with).
So what if 0.001% of requests hit a disallowed resource and you ban those IPs? That's approximately 0.001% of the traffic that you're currently experiencing. It does not solve your problem at all - the excessive traffic that is disrespecting ratelimits and gumming up your service for other well behaved users.
Why would it be only 0.001% of requests? You can fill your actual pages with links to pages disallowed in robots.txt which are hidden from a human user but visible to a bot scraping the site. Adversarial bots ignoring robots.txt would be following those links everywhere. It could just as easily be 50% of requests and each time it happens, they lose that IP address.
Users have poor leverage over ISPs. A lot of them still don't support IPv6 out of unmitigated laziness. If they provide it but violate the standard there isn't much you can do about it, so what the standard is really doing is preventing you from mitigating it.
The standard requiring an entire /64 for SLAAC is also just a poor design.
Suppose your ISP is doing the right thing and giving you at least a /56. You have a complex network with your own subnets and you're not sure how many you'll need in the future, but the spec says you only have to give each one a /64 and that seems like plenty, so the person setting up the network does that. Time passes and you get devices in various subnets with fixed addresses you need to stay fixed. Then you want to hook up a VM host or anything else that wants to further subdivide the address space, but the spec says you can't even though there are still scads of addresses. And for what, so they can use EUI-64 which in practice is only 48 bits anyway and is effectively deprecated because it's a privacy fail?
> To make room for VRAM, memreserver allocates system RAM based on used VRAM plus 1 gigabyte, then fills the RAM with 0xFF bytes and mlocks the memory (so none of it is swapped out).
That seems like a bit of trouble if you have 16GB of system RAM and a 24GB GPU.
You have a firewall at the edge of the network. It blocks incoming connections by default, but supports Port Control Protocol. The cacophony of unpatched legacy IoS devices stay firewalled because your ten year old network printer was never expected to have global connectivity and doesn't request it. End-to-end apps that actually want it do make the requests, and then the firewall opens the port for them without unsophisticated users having to manually configure anything.
The protocol is an evolution of NAT-PMP (RFC6886) for creating IPv4 NAT mappings, but RFC6887 supports IPv6 and "mappings" that just open incoming ports without NAT.
Sure, but is it actually a feature you want, though? We're never going to run out of legacy unpatched devices, and today's shiny new devices are going to be tomorrow's tech debt. If you support that kind of hole punching, sooner or later you will end up with vulnerable devices exposing themselves to the internet.
There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
In my opinion the current kind of hole punching is a far better option: instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet. It's well-researched when it comes to the interplay between firewalls, NAT, and UDP[0].
And that pretty much solves the problem, to be honest. These days you only really need incoming traffic to support things like peer-to-peer video calls. Hosting game servers on your local machine is a thing of the past, everything has moved to cloud services. What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
> We're never going to run out of legacy unpatched devices, and today's shiny new devices are going to be tomorrow's tech debt.
It's not about new or old. The devices that don't have any reason to be globally reachable never request it. New ones would do likewise.
Devices that are expected to connect to random peers on the internet are going to do that anyway. It's not any more secure for them to do it via hole punching rather than port mapping; causing it to be nominally outgoing doesn't change that it's a connection to a peer on the internet initiated by request of the remote device.
> There's no way in hell enterprise admins are going to give that kind of control to random devices, and home users aren't going to have the skills to cull vulnerable devices from their networks. So who's going to use it?
Enterprise admins can easily use it because they have control over the gateway and how it answers requests, so they can enable it for approved applications (in high security networks) or all but blocked applications (in normal networks), and log and investigate unexpected requests. They should strongly prefer this to the alternative where possibly-vulnerable applications make random outgoing HTTPS connections that can't easily be differentiated from one another.
Whether they will or not is a different question (there are a lot of cargo cult admins), but if they don't they can expect their security posture to get worse instead of better as the apps that make outgoing HTTPS connections to avoid rigid firewalls become the vulnerable legacy apps that need to be restricted.
Home users are already using NAT-PMP or UPnP and this has only advantages over those older solutions.
> instead of creating a mapping allowing essentially unrestricted access from everyone, have the app use an out-of-bounds protocol to allow a single incoming connection from exactly one vetted source. You get all of the benefits of a direct peer-to-peer connection with none of the risks of exposing yourself to the internet.
There are significant problems with this.
The first is that it's a privacy fail. The central server is at a minimum in a position to capture all the metadata that shows who everyone is communicating with. It's made much worse if the payload data being relayed isn't end-to-end encrypted as it ought to be.
But if it is E2EE, or the server is only facilitating NAT traversal, the server isn't really vetting anything. The attacker sends a connection request or encrypted payload to the target through the relay and the target is compromised. Still all the risks of exposing yourself to the internet, only now harder to spot because it looks like an outgoing connection to a random server.
Worse, the server becomes an additional attack vector. The server gets compromised, or the company goes out of business and the expired domain gets registered by an attacker, and then their vulnerable legacy products are presenting themselves for compromise by making outgoing connections directly to the attacker.
Doing it that way also requires you to have a central server, and therefore a funding source. This is an impediment for open source apps and community projects and encourages apps to become for-profit services instead. The central server then puts the entity maintaining it in control of the network effect and becomes a choke point for enshitification.
Meanwhile the NAT traversal methods are ugly hacks with significant trade offs. To keep a NAT mapping active requires keep-alive packets. For UDP the timeout on many gateways is as short as 30 seconds, which prevents radio sleep and eats battery life on mobile devices. Requiring a negotiated connection is a significant latency hit. For real peer to peer applications where nodes are communicating with large numbers of other nodes, keeping that many connections active can exceed the maximum number of NAT table entries on cheap routers, whereas an open port requires no state table entries.
> What's left is a handful of nerds running servers for obscure hobby projects at home, but they are more than capable of setting up a static firewall rule.
The point is to allow interesting projects to benefit more than a handful of nerds and allow them to become popular without expecting ordinary users to manually configure a firewall.
> It's not about new or old. The devices that don't have any reason to be globally reachable never request it. New ones would do likewise.
Doesn't this assume all devices are well behaved, trusted and correctly implemented? You don't think the crap Samsung Smart TV will consider itself to have a reason to be globally reachable?
Most of them actually wouldn't because they have no reason to do it and creating the mapping for no reason is work. Making the thing where you're not exposed to the internet the thing that lazy developers get by default is a win.
Some of them could do it for no reason, but they could also have the devices make outgoing connections to the company's servers and then blindly trust any data the servers send back, even if the servers are compromised or the domain expires and falls into the hands of someone else, or the company's own servers are simple relays that forward arbitrary internet traffic back to their devices.
If a device can make outgoing connections then it can emulate incoming connections. Blocking incoming connections to devices that explicitly request them is therefore not a security improvement unless you're also prohibiting them from making any outgoing connections, because the result is only that they do it in a less efficient way with more complexity and attack surface and less visibility to the user/administrator.
Interesting, I haven't read much about that. I've always assumed somebody must have written an RFC to automate how home firewalls should be configurable automatically by software that "wants to" allow incoming connections. Good to see that it exists.
But it doesn't seem to be in widespread use, does it? Like, would a random internet gateway from podunk ISP support this? I kinda doubt it, right? Pretty sure the default Comcast modem/router setup my mom uses doesn't support this.
But I guess my point was about the contrapositive universe where IPv6 was actually used everywhere, and in that universe I suppose RFC6887 might have been commonplace.
Every ISP router I've had with even basic IPv6 support has supported PMP. Every home router I've handled with IPv6 support has supported it. So IME it is in pretty widespread support. Maybe there's some devices out there that don't, but it's at least as wide as UPnP support which was pretty wide.
Things like this can be useful without 100% penetration. Most end-to-end apps support a direct connection as long as either of the endpoints have an open port. Endpoints without one can also fall back to relays, but since port mapping is frequently used in gaming, that has higher latency and then users start demanding gateways that support the thing that lowers lag.
Then it starts to make it into popular internet gateways. For example, the Comcast consumer gateways generally do support UPnP, which is a miserable protocol with an unnecessary amount of attack surface that should be transitioned to Port Control Protocol as soon as possible, but it demonstrates you can get them to implement things of this nature.
It's not the developers who did this, it's the "network security" people. If you block all outgoing ports except for HTTPS and ssh, everything is henceforth going to be tunneled over HTTPS or ssh.
This is also the reason why, if you allow outgoing HTTPS connections, you should as a general rule be allowing all outgoing connections except for SMTP. Because actually malicious traffic is just going to be tunneled over HTTPS anyway and all you're doing is inhibiting the deployment of any new protocols that don't take on the complexity and inefficiency of the tunnel.
It's an extremely common exception for exactly the reason you don't like it. If you block it you get widespread breakage because so many things use it. Then even more things use it because it's allowed and novel protocols aren't.
And what do you think happens in the places that do block ssh, instead of unblocking other things? I hope you like VSCode over ssh over HTTPS VPN.
Not really. The era of "modern efficient CPUs" started some 10-15 years ago. Under light loads, Ivy Bridge or Haswell is going to have a similar thermal profile to modern machines.
Many of the new machines are actually worse, e.g. 3770K @77W vs. 14900K @125W/253W. That isn't to say they're not also faster, but if you actually use it you're burning more watts.
LLMs are essentially predicting what token could plausibly come next. They sort the possible next tokens by probability, often throw out the the ones with very low probabilities (p-value too low) and then use a weighted random number generator to choose one from the rest.
Sometimes that means you exclude a good next token, or include a bad one, so a bad one gets chosen. And then once it has, the thing is going to pick whatever is most likely to come after that, which will be some malarkey because it has already emitted a nonsense token and is now using that as context. But whatever it is, it will still sound plausible because it's still choosing from the most likely things to follow what has already been emitted.
A p-value isn’t just any old probability- it has a specific meaning related to hypothesis testing[1]. A p-value is the conditional probability of seeing a result at least as extreme as some observation under the null hypothesis.
Yes LLMs generate tokens using a stochastic process, so it is probabalistic. Everyone knows that, but in the normal process of generating text, LLMs aren’t doing a hypothesis test so by definition p-values are completely irrelevant to how LLMs hallucinate.
This is such a common thing to misunderstand that I'm going to respond to my own message to give an explanation, because many of the links I've found make sense once you know the lingo etc but might not before then.
Say you go into a bar and just by chance there is a football[1] match on television between Denmark and France. You see a bunch of fans of each country and you think "Hey, the Danes look taller than the French". You want to find out whether this is true in general, so to test this hypothesis you persuade them during a lull in the match to line up and get measured. As luck would have it there are exactly n people from each country.
H_0 (the null hypothesis) is that the two population means are the same. That is, that Danish people have the same average height as French people.
H_1 (the alternative hypothesis) is that Danish people are taller on average than French people (ie the population mean is larger).
So you take the average height and see that the Danes in this bar are say 5cm taller on average than the French people in this bar.
The p-value is how likely it would be to select a random sample of n people from each of two populations (one from Danes, one from French people) with an average height of the Danes in the sample being at least 5cm larger than the French if the actual average height of the underlying populations you sampled from (all Danes and all French people) were the same.
How you use a p-value is typically if it is smaller than some threshold called a critical value you "reject the null hypothesis" at some significance level. So in this case if the p-value was small enough you conclude that the population means are unlikely to be the same.
Actually calculating the p-value is going to depend a bit on the distribution etc but that's what a p-value is. As you can see it's not just a probability.
I was vaguely aware of this and I don't know if I want to say I was just being careless or if that was the point because the original comment was kind of a mess and I was defending it in jest.
Reaching the scale where it shows actual returns isn't all that difficult. You need it to happen 7.6 million times to save 1 CPU second, but each CPU core can execute it nearly that many times every second.
Probably you don't leave it generating only random numbers all day, but suppose you do generate a good few, so that it's 1% of your total compute budget, and you have only a modest load, using on average four CPU cores at any given time. Then saving that amount of computation will have saved you something like $15/year in compute, recurring. Which isn't actually that bad a return for ten seconds worth of choosing the right function.
There are also a lot of even fairly small entities for which four cores is peanuts and they're running a hundred or a thousand at once, which quickly turns up the price.
And even the things with internet scale aren't all that rare. Suppose you're making a contribution to the mainline Linux kernel. It will run on billions of devices, possibly for decades. Even if it doesn't run very often, that's still a lot of cycles, and some of the kernel code does run very often. Likewise code in popular web browsers, javascript on popular websites or in popular libraries, etc.
You don't have to work for Google to make a contribution to zlib and that kind of stuff has the weight of the world on it.
You're trying to catch the specific implementation of the attack rather than the general attack. Suppose they don't lie about the size of the memory, instead they find a way to mask out one of the address bits so reads from higher addresses go to lower addresses or vice versa. Which they can change in hardware at runtime after you've done whatever checks you want and which doesn't necessarily have to be the most significant bit.
Oh, I'm sure, but this just seems like an oddly simple exploit that seems to rely on things that almost look like they shouldn't work.
Like you'd think things like address lines being shorted together, or not being connected, or such things would be simple to test for in a millisecond or two, and be a logical part of a basic test of functionality that just checks that everything seems to be wired up right.
