The Chromium issue is not public yet, so let's go with a very simple example.
Let's say that you have a type confusion bug that (in terms of the interpreted language) allows you to use an Integer variable as an Array.
That sounds nonsensical when just considering the high-level language, but your computer is going to need something to work with when running a script. For an Integer variable it will for example store the value, and for an Array it would store a pointer to a data area (and that area then contains values).
Now, if the interpreter loses track of which type a certain variable is, then it will also not know whether to interpret the internal data as a plain value (arbitrarily chosen by the script/attacker) or a pointer to well-formed data (carefully chosen by the runtime).
As an immediate step, letting the attacker use an address of their choosing for array operations would allow them to read and write arbitrary memory that is reachable with this form of addressing.
I'm putting specific emphasis on "form of addressing" here, because the v8 authors have considered this possibility and put additional protections in place. Within the sandbox, "addresses" are limited to a size of 32 bits, and address within a dedicated 4 Gigabyte area that is specifically for interpreter data. Within that area you are not going to find a lot of critical data to affect outside operations, you'd have to find a way to escape that memory area first.
The next part is going to be a bit hazy because it's been some time since I did Chromium exploitation, and getting code execution within the sandbox from data writes is itself not an easy task.
Now, we have established that there is not a lot of terribly important data within the 4 GB area. The data managing the interpreter lives outside, and any JITed code will also live outside because it needs different access permissions. We only really get to play with Objects and their data.
Objects handling executable code are rare, but there are a few that are at least adjacent. Last time I checked, WASM was one feasible choice where you get reasonably predictable results with custom data, as it included a pointer to actual executable code that represents the WASM program.
Under the assumption that the WASM interpreter/compiler does its job correctly the full block of executable code will not be very interesting. However, any integer constant in the program will end up somewhere within the executable code, and that would give you enough controllable data to encode one or two arbitrary instructions and a relative jump to the next integer constant. To start execution at the first integer constant, we'd then just modify the Object data of the WASM program to slightly offset the entrypoint.
And that's the short form of a possible (and likely outdated) way of getting semi-arbitrary code execution within the sandbox (as we are running as a WASM program, and therefore have all the usual syscall restrictions and other security features engaged).
I appreciate the thorough explanation... you seem to understand the domain... but I still don't get how this would work in practice. My experience with C/C++ is somewhat limited but I imagine V8 does something like reserve a whole bunch of addresses and then manage them itself, with some internal list where script arrays/objects correspond to blocks. Or maybe it delegates some of that to C++ vectors that can scale up. But what scripted integer or array could you pass it that would access anything already freed or outside the bounds of the addresses that array was mapped to? The only thing I can think is some kind of asynchronous wipe that would allow the engine to write other data to that block, and using a race condition to access it after it was free. But that doesn't sound quite like a type confusion.
What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox? Wouldn't that have been accounted for in the most basic design?
I'll have to note that I'm probably way worse than anyone doing this professionally or semi-professionally. This is the extent of what I learned as part of university, which was exclusively using planted vulnerabilities. The knowledge required to find and exploit such issues in a real-world scenario goes much deeper. My dayjob in security is on the entirely opposite side, since I'm doing defensive security on the system-level.
In short, it is quite likely that someone may join in and point out where my information is outdated or plain wrong. (Please do so!)
> My experience with C/C++ is somewhat limited but I imagine V8 does something like reserve a whole bunch of addresses and then manage them itself [...]
That is essentially correct, that's what the 4 Gigabyte allocation I mentioned before is. Let's call it the "v8 heap", because it is distinct from the heap that your system manages (which is the one used for `malloc` and `new`), but it will largely work in the same way.
> [...] with some internal list where script arrays/objects correspond to blocks.
v8 does have a lot of internal checks to make sure that what it is touching looks sane (at least on debug builds), but it will not have a lot of duplicated information. Having to check or update information in multiple places is both an artificial limit on performance as well as its own source of bugs (if not kept in sync correctly).
If v8 needs a JavaScript Object then it will simply ask the v8 heap for an appropriately sized memory allocation and fill in its data there, not unlike normal C or C++ objects (except that v8 usually refcounts, I believe). After this it will simply continue to work with the pointer that it already has.
> But what scripted integer or array could you pass it that would access anything already freed or outside the bounds of the addresses that array was mapped to?
You need to keep in mind that in this scenario, reading/writing outside the intended memory area is already the effect that we want to achieve, it is not the vulnerability.
We are not abusing some insufficient bounds check on an existing Array, _we make v8 believe that there is an Array_ (or at the very least something that it can use like one; in either case it's completely made up), and it happens to have its data stored at the location and length that we want.
> Wouldn't that have been accounted for in the most basic design?
Yes, and for that reason the interpreter itself is considered pretty much battle-tested. However, in search for more performance, multiple JavaScript engines have turned towards engineering Just-In-Time compilers to accelerate running code that runs so often that the compile overhead is worth it. v8 / Chromium / Google alone have a set of three JIT compilers (Sparkplug, Maglev, TurboFan) that compile interpreter bytecode to actual machine instructions depending on what is currently required and how fast the resulting code should be.
> What's an actual snippet of pseudo-JS that could make the engine overrun its memory and start reading out of arbitrary addresses, even within the sandbox?
Those are a bit hard to come by, even more so since the focus for v8 exploitation has changed to targeting the JIT compilers. This usually means that a lot of the exploit would be concerned with wrangling the compiler into place.
I'll try to give an example of what a type confusion involving the JIT compiler looks like, but this is based on work by my classmates, since I never finished that particular part of the exercise.
It is also recited purely from recollection, since I'm not near my university notes.
To get the best possible code optimization the compiler wants to work with some assumptions. If any of those don't hold anymore, the compiler should either never have optimized or at the very least it should deoptimize before anything happens and fall back to a more flexible way of running that code.
One such nugget of information is whether certain well-known properties (let's say .name) can have side effects, those are kept as lists in the source code of the compiler [1]. If the compiler is told that .name can not mutate its object (contrary to the specification and the remainder of the v8 implementation), then it may choose to elide type change checks within the optimized function (that has already been optimized for a specific type) and miss a deoptimization.
If v8 then uses the optimized function after it should have been deoptimized, we essentially get a function that uses an area of memory as if it were a different type of object.
PS: I should get back into this, even just explaining already-done things sounds fun.
Wow. If I understand, your .name example kinda blows my mind. So that would be where the JIT compiler might be pre-optimized to expect a certain length for a supposedly immutable parameter... right? Even if the spec makes everthing mutable. I didn't know that was part of the optimization, but it makes some sense.
That makes it possible for me to visualize how a use-after-free might work inside a JIT engine's sandbox. If I'm not misunderstanding, you're saying that the type confusion attack could be accessed by changing something as simple as the prototype for Object, in a way that the JIT compiler was hardcoded to ignore? Essentially that the compiler is not built to spec, and then getting the garbage collector to somehow free the extra memory, it's still possible to open a hole to read sequential blocks. But the main flaw would be that the compiler reserves X memory for quickly writing an object and then in some unoptimized phase sees that the object only took up X-y and reuses a portion of it...?
I'm a high school dropout..Am I seeing this right?
Is that with vanilla llama.cpp or with the third-party llama-swap manager? Last time I checked llama-swap was still the go-to solution, although I admit I haven't looked into it further.
The router mode and matrix routing in llama.cpp is still early days and it can't easily juggle multiple models as easily as llama-swap so there's still benefits if you're using 24-32GB cards that can run multiple models simultaneously.
The gulf is quickly shrinking though and it seems like the need for llama-swap will disappear soon.
If you revisit my comment and pay attention to the opener:
> but you might not be aware that llama-server can do multi-model for a while now
you will see that the sentence structure clearly implies both a change compared with a prior state and also lack of any third-party thing.
So the answer to the question has already been encoded as text available.
_
I can see the desire for explicit validation though. For that, I would propose a sentence structure like
> Oh cool! That means that llama-swap is now superseded/no longer needed?
That shows that you've read and understand the message, gives you the double-check and might on top spark a conversation about how these solutions compare.
Plus that if the guy you're commenting too has spoken nonsense, they need to backpedal.
btw, llama-swap provides a nice UI for monitoring performance and logs, and even the ability to stop an infinite session that consumes GPU resources (sometimes that happens).
Does the llama.cpp UI provide the same? If not, it is too early to say that llama-swap is “superseded/no longer needed.”
If you are talking about the addition of microG, that indeed seems like it hasn't been mentioned on the blog, although I'd argue very likely due to an oversight.
I can find internal conversations that it deserves to be announced in a more prominent way than on the "Sunsetting LineageOS 18.1" post, was left as "to be added to the LineageOS 22.x" blog post, and then just never made the initial draft. Whoops.
If you are talking about the rules on the subreddit (or the other social platforms), that one indeed has been discussed a lot on the platform itself (and which we usually keep available).
> They stopped that malpractice a while ago (last year?).
By now it has actually been almost two and a half years.
> But they really hurt their credibility with the prior stance, and that their subreddit still has rules forbidding almost all discussions [...].
While I'm not looking to turn this into an off-platform meta discussion, pretty much all of those rules have their very good reasons to be there.
As an example, you would be surprised how many people install a Magisk module to strip away LineageOS-specific build version properties, and then end up in our support platforms asking why the Updater can't search for new updates (of course while not mentioning that they have modified their system).
microG I don't even see listed as a part of any rule anymore, it was removed when upstream support for microG was merged.
You are correct, the microG ban is gone from the sidebar. That's nice.
(Why this was so important: During covid the official contact tracker in Germany needed microG/the play services, a newer alternative then bundled the scanner or something, so worked without. But that took time and was less official. When it becomes life and death impractical positions like that hurt).
It's okay if you dont want to discuss it. To share my position anyway: You need the option to have root so the device belongs you (and not the Rom), VoLTE is an existential threat and the ban stiffles all options to easily get information about the situation. That's the main point: Banning topics completely does only make things worse, and it is not like the project tried not to ban these topics for how many years now, a decade? An Autobot answer should suffice for making the problems known.
The developers of each have engaged in a few flamewars and the commenter I replied to was critical of GrapheneOS using similar language, so I made a (tongue in cheek comment) implying the commenter was starting the flamewar back up
Every system and package manager will be affected if it cannot download source code to build a package.
NixOS less so, because pretty much all source downloads that are not restricted by license are a separate output that will therefore be stored on (and downloadable from) NixOS cache servers.
I'm not sure what your expectation for this is in general, nobody can just wish into existence data that is just gone.
Thanks Tim… my memory is fuzzy - that was a lot of phones ago.
… and thank you for your continued effort! I have very big love for CyanogenMod/LineageOS, and that’s coming from a heavy pre-XDA user (I’ve had them all - PalmOS, Zaraus, XDA o2, Maemo, FirefoxOS, Ubuntu phone user).
Let's say that you have a type confusion bug that (in terms of the interpreted language) allows you to use an Integer variable as an Array.
That sounds nonsensical when just considering the high-level language, but your computer is going to need something to work with when running a script. For an Integer variable it will for example store the value, and for an Array it would store a pointer to a data area (and that area then contains values).
Now, if the interpreter loses track of which type a certain variable is, then it will also not know whether to interpret the internal data as a plain value (arbitrarily chosen by the script/attacker) or a pointer to well-formed data (carefully chosen by the runtime).
As an immediate step, letting the attacker use an address of their choosing for array operations would allow them to read and write arbitrary memory that is reachable with this form of addressing.
I'm putting specific emphasis on "form of addressing" here, because the v8 authors have considered this possibility and put additional protections in place. Within the sandbox, "addresses" are limited to a size of 32 bits, and address within a dedicated 4 Gigabyte area that is specifically for interpreter data. Within that area you are not going to find a lot of critical data to affect outside operations, you'd have to find a way to escape that memory area first.
The next part is going to be a bit hazy because it's been some time since I did Chromium exploitation, and getting code execution within the sandbox from data writes is itself not an easy task.
Now, we have established that there is not a lot of terribly important data within the 4 GB area. The data managing the interpreter lives outside, and any JITed code will also live outside because it needs different access permissions. We only really get to play with Objects and their data.
Objects handling executable code are rare, but there are a few that are at least adjacent. Last time I checked, WASM was one feasible choice where you get reasonably predictable results with custom data, as it included a pointer to actual executable code that represents the WASM program.
Under the assumption that the WASM interpreter/compiler does its job correctly the full block of executable code will not be very interesting. However, any integer constant in the program will end up somewhere within the executable code, and that would give you enough controllable data to encode one or two arbitrary instructions and a relative jump to the next integer constant. To start execution at the first integer constant, we'd then just modify the Object data of the WASM program to slightly offset the entrypoint.
And that's the short form of a possible (and likely outdated) way of getting semi-arbitrary code execution within the sandbox (as we are running as a WASM program, and therefore have all the usual syscall restrictions and other security features engaged).
reply