As far as I am over-clarifying all my not-too-evident post for the (unfortunately) huge number of poorly-understanding individuals, note that Corporate is a new very funny TV series (the one referred in the Wikipedia article linked from the aforementioned smiley) about a fictitious company called Hampton Deville. The title of this article is "Amazon Is Cutting Hundreds of Corporate Jobs" and that's why "Hampton Deville should have seen that coming" was meant to be funny because of playing with the unintended double meaning of "corporate" (generic adjective vs. the name of that TV show). It was just moderately funny, that's why I put ":)" rather than "LOL". Just a relaxed pun also meant to let anyone interested about that new looking-really-good-so-far show. Any person having still problems to understand the exact meaning of that previous post should better avoid dealing with me. Thanks. LOL.
Clarification for really-bad-at-understanding individuals: that previous post was sarcasm and, consequently, it really meant pretty much the opposite than what is written (e.g., executives usually making very stupid decisions). Anyone with basic understanding skills should be able to immediately get that point without too much help (knowing a bit about me, just what is written in my bio here, doesn't even seem required). I also wrote some additional help for those with bad understanding skills: the ending "LOL" (= "laughing out loud") should be understood as an undoubted indication that the whole post was a joke. Despite all that, I still think that some people might find it too confusing and that's why this further clarification. Also bear in mind that I am a quite prejudice-free person and, as such, cannot think that all the executives (understood as high-level managers, quite detached from the actual activity of the given company and with low-to-no real knowledge about it) are extremely stupid.
(Sorry about the delay in replying. I saw your post right now by pure accident. Bear in mind that one of the drawbacks of posting anonymously here is that I don't get any warning when you reply to one of my posts).
So, you are saying that proving a concept is "developing" a piece of software not doing anything at all to prove the given concept? You are saying that writing a simple loop reading/displaying the words included in a simple array (a song or a poem or just a random nonsense), making ridiculously inaccurate claims in the readme file and getting over 400 stars is proving something? Perhaps you are right. It definitively proves something: the huge amount of dishonesty and/or lack of knowledge and/or gullibility and/or fanaticism that you can easily find in (certain areas of) internet.
If the idea you want to prove is that it is possible to know certain memory addresses which, in theory, shouldn't be known by that user/process, you would have to perform some actions to accomplish that goal (why these specific addresses should be hidden? Under which conditions you can know about them and how that access could be avoided?, etc.), via comments, different I/O scenarios or similar. This would have been an acceptably good PoC, but still not what I was looking for. If you want to deliver what I think that is the basic requirement to consider this a serious problem, you would have to work a bit more. Additionally to the aforementioned proof that the given memory addresses shouldn't be known, you would have to also prove that you can access the contents stored in said addresses. Or more graphically: after proving that the address 0x000whatever shouldn't be known by the given user/application, you would have to be able to prove that program2 can retrieve from that memory address the character 'a' that program1 stored there (= code actually performing the advertised real-time reading of Chrome passwords).
Density or strength (to whatever type of stress) are very relevant features for certain kind of materials, but somehow secondary when thinking about replacing steels or plastics. If you want a strong material regardless of any other thing, you would use something like cement rather than steel. Steels and plastics are strong, but also easily deformable.
On the other hand, there are some scenarios where flexibility doesn't matter much and steel is used anyway; also "stronger than steel" seems a quite catchy headline to get some attention. In any case, using that material to build something like a car seems a quite unlikely scenario because wood is intrinsically brittle.
The flaw I see in your reasoning is that most of privacy concerns are about resource management/computer usage rather than hardware architecture.
When being online, you are voluntarily storing information in third-party computers being managed by people who, in some cases, might not treat it according to your expectations. Another typical concern is hardware manufacturers monitoring users' activity against their will; again, this has nothing to do with the given architecture as far as they could always do something like that. A third type of threats are viruses; they are usually meant to emulate users' behaviour and, as such, are potentially able to do exactly the same than the given user regardless anything else.
I agree with quite a few of the posts above about seeing lots of lacks on the honesty, common sense, openness, objectivity, quality, dependability, etc. fronts.
On top of that, it would also be nice if clueless decision makers (with neither technical knowledge nor basic understanding skills) would be reduced or, ideally, completely removed. I mean managers, recruiters, investors, proceedings, expectations, requirements, trends, etc. unreasonably constraining different aspects of the technological (at least, software/programming) world. Or, in other words, avoiding ignorance to have anything to say at all, what seems like an easy goal for a knowledge-intensive field.
I don't have too many abstract fears, but if I have to guess the most likely responsible for whatever catastrophe I would stick to human stupidity. Something like being afraid of what is quite unlikely to ever exist seems a good example.
Executives coming up with innovative ideas! Let's apply them right away! What could possibly go wrong? If more executives had their voices heard, there wouldn't be problems in the world! I want an executive in my life! Anyone knows where can I get a discount one? LOL.
Just in case anyone has the slightest doubt, with "if they deliver", I meant doing something on the lines of what they did yesterday. Manned trips to Mars will not happen within the next many years, perhaps ever.
Yesterday's video was quite nice. Not sure about how relevant is being nice for something like space exploration, but if they deliver there shouldn't be any problem.
Just in case this point isn't clear to everyone, the famous Meltdown bug (exemplified precisely with an attacker reading in plain text the passwords you type in Chrome) belongs to a completely different level of problems. This article is about the given application/process (for this purpose, a plugin can be considered part of the same application) leaking some of the information which the user stored in it. Meltdown is about a different application/process presumably reading information of the target one (Chrome/plugin in this case) which is stored in the given computer's memory.
A quite descriptive analogy would be forgetting your wallet somewhere vs. someone reading your mind to know where your wallet is. I am not implying that exploiting meltdown is as unlikely as reading someone's mind, but it doesn't seem too easy anyway (not sure though). Anyone wanting to share some insights into all this is welcome to a previous discussion about it.
Clarification just in case: regardless of the tremendously low quality (+ dishonesty; please, refer to the aforementioned repository including a doing-nothing simple file with 400+ stars in GitHub!!) of some of the available codes, the whole meltdown premise seems very difficult (if possible at all) to be exploited as far as one thing is knowing certain memory addresses and a completely different story is being able to actually retrieve information which is stored there. In any case, note that most of my experience is focused on the algorithm-developing side of things by eminently relying on managed languages. I have some low-levelish experience (in C), but knowing how everything is working at the memory-level is certainly not my strongest suit. Perhaps I missed something. As said, more than happy to get any kind of feedback or tangible references (= pretty much the opposite to a video showing random numbers, incredible claims without code/programs to support them or similar faith-based resources).
OK, look let's rewind.
I think we were talking at crossed purposes and got pissed off at each other.
I didn't get pissed off by anything you said, I simply accepted that no worthy discussion was possible. I openly said that to you and you were the one getting pissed. This last post of yours reconfirms my original assumption: you are back to your let's-convince-everyone-that-they-have-to-like-what-i-do loop. Please, don't get offended and try to understand the ideas which I am explaining below these lines which aren't too difficult.
I shared here my opinion about Rust by clearly explaining the context (= new to the language, quick test with a small development together with other languages on which I had no experience either, quite experienced in different programming languages and used to move from one to the other, etc. BTW, nobody has asked me about that code which is written in quite a few different languages other than these 4 ones; if I was you, the first thing I would like to see is the code, isn't that all what should matter here?). You and most of other Rust-defenders (Rustaceans, I think that you call yourselves) didn't understand my intention and words within the right context and simply started to blindly defend the benefits of it, something which I wasn't asking and that doesn't even seem a sensible reaction to my original post. None of your arguments have even tried to address the main issues which I was criticising (= unfriendliness, rigidity, lack of adaptability, etc. in general making the programming experience unnecessarily difficult unlikely many other languages), just coming up excuses for it. You have simply tried to prove what is evidently impossible to be problem: that there is no better way to do things! There are tons of better ways! Just the other 3 languages I tried in this small experiment do things notable better on this front!
In my previous message, I saw a glimpse of sensitivity and tried to help you understand one last time. Your answer? Coming back to do exactly the same than you have been doing since the start: blindly defending something which I am not attacking and/or trying to convince me about what I don't care! The only sensible reply to someone saying that found whatever programming language (BTW, I cannot understand this intense feelings for a so abstract and saying-nothing reality like a programming language!! They are mere tools! If they don't behave as they should, just use a different one!! There are tons of them!!) unappealing for whatever reason is accepting that or, in case that you care about the opinion of that person, perform the corresponding changes. But why trying to convince me (well... this would have required sensible arguments; it has been mostly some kind of pushing, pressuring, bullying, attacking, trying to force, etc.) to like the language which you do?! How can you think that the normal reaction to someone saying "I don't like that" is "you have to like it"!! Why? Can you see in any of my comments to you or to anyone else even the slightest attempt to push anyone to like whatever or to stop liking what they do? You can only see things on the lines of "I like X", "I dislike Y" + some context references ("note that my background is Z").
Can you finally understand why I didn't want to continue this "conversation", why I temporarily thought that I could get through to you and why that last comment has confirmed my preliminary assumptions and that I will better not be talking to you (certainly not about your sacred bits like Rust)? I am not trying to criticise you, define your personality or even say that your behaviour is wrong (if you are happy and not hurting anyone, everything is fine with me), I am trying to help you understand what you don't seem to be able to see here: there is nothing for us to discuss. No hard feelings. I am simply not willing to be patient with certain attitudes. If you want to have any discussion about whatever issue by relying on what I consider basic requirements (properly
This has been weird... I have posted right now a reasonably big reply with conclusions after some tests/research which hasn't been stored. A bit tired I guess. I am not willing to re-write everything. The short summary is that I wasn't able to find a way for a process, supposed to only access a given address space (its regions are defined in/proc/PID/maps; this is the most similar thing I could find to your "base address"), to do anything with the memory allocated by another one. Regardless of the fact that certain highly sensitive, OS-accessible memory isn't properly managed, the question of how to access that memory remains. Even under ideal conditions (admin privileges, perfect information about the memory addresses and data types), a process running on the give OS can only access memory locations within its assigned range.
How can this be overcome? How can all these memory-dumps become useful? How could that famous-but-not-found-so-far app able to read passwords from Chrome be built? Even by having all the information regarding the memory location of the given strings, how could them be read by a random process? I think that this are all the main ideas which I wrote in that longer-&-now-lost post. If I misunderstood any bit or anyone knows about a ready-to-use sample delivering a tangible result, please let me know.
Well... your attitude in this post seems notably different. Sorry if I misinterpreted you or expressed myself poorly.
Regarding your "You seem to know nothing about the technical nature of Rust, nor its use in practice and yet you're arguing vociferously about it.", just want to clarify that I haven't ever hidden my limited knowledge about Rust. In fact, the whole point of my comment since the start was describing how unfriendly I found it as a newcomer (despite my relevant expertise and adaptability on the programming-language front). Also as highlighted in other comments (+ at least IMO, the most logical interpretation of my behaviour), I think that critics should be welcome or ignored; getting offended or not wanting to properly understand them doesn't seem to make too much sense. I have merely shared my honest and objective opinion which, ideally, might be useful to further improve on certain fronts. Even though I currently don't like Rust at all, I might change my opinion in the future; many other programming languages have gone through a relevant evolution.
because the password is stored in some easily guessable memory location
Not just easily guessable, exactly the same every time!!! What sounds quite weird! At least, by looking at what these codes are supposed to be doing, they are generating memory locations regardless of anything else including Chrome!! The underlying idea is that Chrome stores all the passwords (and only the passwords!) in the same memory locations (which might change from computer to computer or even after restarting it, but which are the same for all the running applications)!!! Lots of very weird assumptions, but well... these might be extremely faulty codes, not saying that this is a basic requirement for the referred bug (no idea though).
Another issue I didn't mention but which you correctly pointed out: the memory location has to be added to the base address of the given application, what represents an additional difficulty (+ finding out said base address). Easy? No instructions? Weirder and weirder! Anyway, I will give it a try in some hours and share my impressions.
Take any of the PoCs outputting memory. Set that start address to the base address of your target application (how to get this depends on the OS. In Linux you can look in/proc) or the kernel. Run the PoC, pipe the output through strings. Data will show up.
Let's see if I understand you correctly. Consider the following C code:
char char1 = 'a';
printf("%c", char1);//the value of char1, a. printf("%p", &char1);//memory address where char1 is stored. char* char2 = &char1; printf("%c", *char2);//same value than char1, a. printf("%p", char2);//same memory address than the one of char1.
You can play around with the memory locations of all the variables (+ get their values) as much as you want within the same application. Now, if I print the value of the aforementioned memory location to a file and, while that program is still running, I execute a second program which reads that file and tries to get the value associated to that memory location, an error will happen because that memory address will not make any sense for that second program. But, due to this bug, there are cases where that situation can occur (reading certain memory location from a different application and getting the value stored there by that original application). Some of the listed codes generate a set of memory addresses with that "feature" which consequently can be read from any other application?! If I understand it correctly, it wouldn't be straightforward at all and would imply a ton of assumptions (why a variable is stored in exactly the same memory location? Why the given program, out of the tons of different possibilities, would be relying on exactly the approach allowing that? Is the type of that memory allocation always char? etc.); what makes the referred lack of instructions even weirder! Anyway, I might give it a shot in the afternoon and write here my impressions. Thanks for the explanation.
thousands of people around the world working hard on proving you wrong as we speak
I have so many enemies? Because of something I said? I can change if they want! LOL. Yes, I get your point.
If I could do it myself I would not be publishing my results here for you.
I understand that this is the case with these things (researchers + public work way behind the malicious activity), but there has been so much publicity this time! And, after looking at some of the codes posted in a comment above, my doubts are even stronger. Anyway, it was just out of curiosity as far as I don't consider myself or my computers a target of this kind of things (poor + cautious).
That was from a 5 second google search. I have only tested the top one myself but I know it works.
Thanks and sorry for having been so lazy myself. Anyway, I also looked at the first one and it seems to deliver (didn't run it, just read the docs and saw the video) pretty much the same than what I have seen in some other places: memory dumps (from in principle protected locations). This is kind of demonstrating what the bug is about, but not the real exploit I meant. What I meant with real exploit was an application which might actually be used to perform whatever potentially-dangerous action on my computer. Having access to protected memory isn't ideal, true; but how could all that be easily use to accomplish whatever goal? How could you convert those memory locations into ways to trick whatever software to behave against my intent? Having just a memory dump isn't too useful by itself.
Then, I took a look at the fourth one (with 482 stars!) which is a simple C file, with no instructions that, when executed, prints an a array of strings which might a song or something?! The readme says that it can read password from Chrome?! (by assuming that all the hidden fields are stored in the same way and in the same place in all the OSs, it might make sense but not in any other scenario. And why just Chrome?!). In any case, that code is just running the loop with the song, nothing else(!!).
Then, I looked at the second one which is also a C file but much more complex than the aforementioned sample. This time I cannot know immediately what it does, so I run it and it printed out something about it working and what seems memory locations. Again, no instructions no explanation and, at first sight, no idea how this is supposed to be reading passwords from anywhere. I think that I have now more doubts than before your post (thanks again, anyway)! If reading passwords from a browser is so easy why aren't they including a clear code/application with clear instructions? Or even worse: why all of them are saying that everything works fine, that it is very scary when their codes don't seem to be doing anything? Perhaps I am a bit tired now and am I missing something or what?
I am not saying that it is impossible to be exploited, but much more difficult than what so much advertisement seems to imply. Logically, I am more than ready to be proven wrong. Also I do think that all this should be eventually fixed, at least, under the most demanding/vulnerable conditions. Anyone willing to put together a small virus (not doing anything bad + source code, evidently) to prove me wrong?
Slashdot Mirror
As far as I am over-clarifying all my not-too-evident post for the (unfortunately) huge number of poorly-understanding individuals, note that Corporate is a new very funny TV series (the one referred in the Wikipedia article linked from the aforementioned smiley) about a fictitious company called Hampton Deville. The title of this article is "Amazon Is Cutting Hundreds of Corporate Jobs" and that's why "Hampton Deville should have seen that coming" was meant to be funny because of playing with the unintended double meaning of "corporate" (generic adjective vs. the name of that TV show). It was just moderately funny, that's why I put ":)" rather than "LOL". Just a relaxed pun also meant to let anyone interested about that new looking-really-good-so-far show. Any person having still problems to understand the exact meaning of that previous post should better avoid dealing with me. Thanks. LOL.
Too bad it has been abandoned.
It is in pretty good shape anyway. I have been using it for a while already and no complaints.
:).
a very hard sponge
too expensive
shortages
Good points to further confirm the low suitability of this material for industrial usage at a relevant scale.
Clarification for really-bad-at-understanding individuals: that previous post was sarcasm and, consequently, it really meant pretty much the opposite than what is written (e.g., executives usually making very stupid decisions). Anyone with basic understanding skills should be able to immediately get that point without too much help (knowing a bit about me, just what is written in my bio here, doesn't even seem required). I also wrote some additional help for those with bad understanding skills: the ending "LOL" (= "laughing out loud") should be understood as an undoubted indication that the whole post was a joke. Despite all that, I still think that some people might find it too confusing and that's why this further clarification. Also bear in mind that I am a quite prejudice-free person and, as such, cannot think that all the executives (understood as high-level managers, quite detached from the actual activity of the given company and with low-to-no real knowledge about it) are extremely stupid.
That's what PoCs are, Proof of Concepts.
(Sorry about the delay in replying. I saw your post right now by pure accident. Bear in mind that one of the drawbacks of posting anonymously here is that I don't get any warning when you reply to one of my posts).
So, you are saying that proving a concept is "developing" a piece of software not doing anything at all to prove the given concept? You are saying that writing a simple loop reading/displaying the words included in a simple array (a song or a poem or just a random nonsense), making ridiculously inaccurate claims in the readme file and getting over 400 stars is proving something? Perhaps you are right. It definitively proves something: the huge amount of dishonesty and/or lack of knowledge and/or gullibility and/or fanaticism that you can easily find in (certain areas of) internet.
If the idea you want to prove is that it is possible to know certain memory addresses which, in theory, shouldn't be known by that user/process, you would have to perform some actions to accomplish that goal (why these specific addresses should be hidden? Under which conditions you can know about them and how that access could be avoided?, etc.), via comments, different I/O scenarios or similar. This would have been an acceptably good PoC, but still not what I was looking for. If you want to deliver what I think that is the basic requirement to consider this a serious problem, you would have to work a bit more. Additionally to the aforementioned proof that the given memory addresses shouldn't be known, you would have to also prove that you can access the contents stored in said addresses. Or more graphically: after proving that the address 0x000whatever shouldn't be known by the given user/application, you would have to be able to prove that program2 can retrieve from that memory address the character 'a' that program1 stored there (= code actually performing the advertised real-time reading of Chrome passwords).
Density or strength (to whatever type of stress) are very relevant features for certain kind of materials, but somehow secondary when thinking about replacing steels or plastics. If you want a strong material regardless of any other thing, you would use something like cement rather than steel. Steels and plastics are strong, but also easily deformable.
On the other hand, there are some scenarios where flexibility doesn't matter much and steel is used anyway; also "stronger than steel" seems a quite catchy headline to get some attention. In any case, using that material to build something like a car seems a quite unlikely scenario because wood is intrinsically brittle.
The flaw I see in your reasoning is that most of privacy concerns are about resource management/computer usage rather than hardware architecture.
When being online, you are voluntarily storing information in third-party computers being managed by people who, in some cases, might not treat it according to your expectations. Another typical concern is hardware manufacturers monitoring users' activity against their will; again, this has nothing to do with the given architecture as far as they could always do something like that. A third type of threats are viruses; they are usually meant to emulate users' behaviour and, as such, are potentially able to do exactly the same than the given user regardless anything else.
I agree with quite a few of the posts above about seeing lots of lacks on the honesty, common sense, openness, objectivity, quality, dependability, etc. fronts.
On top of that, it would also be nice if clueless decision makers (with neither technical knowledge nor basic understanding skills) would be reduced or, ideally, completely removed. I mean managers, recruiters, investors, proceedings, expectations, requirements, trends, etc. unreasonably constraining different aspects of the technological (at least, software/programming) world. Or, in other words, avoiding ignorance to have anything to say at all, what seems like an easy goal for a knowledge-intensive field.
I don't have too many abstract fears, but if I have to guess the most likely responsible for whatever catastrophe I would stick to human stupidity. Something like being afraid of what is quite unlikely to ever exist seems a good example.
Executives coming up with innovative ideas! Let's apply them right away! What could possibly go wrong? If more executives had their voices heard, there wouldn't be problems in the world! I want an executive in my life! Anyone knows where can I get a discount one? LOL.
Just in case anyone has the slightest doubt, with "if they deliver", I meant doing something on the lines of what they did yesterday. Manned trips to Mars will not happen within the next many years, perhaps ever.
Yesterday's video was quite nice. Not sure about how relevant is being nice for something like space exploration, but if they deliver there shouldn't be any problem.
Just in case this point isn't clear to everyone, the famous Meltdown bug (exemplified precisely with an attacker reading in plain text the passwords you type in Chrome) belongs to a completely different level of problems. This article is about the given application/process (for this purpose, a plugin can be considered part of the same application) leaking some of the information which the user stored in it. Meltdown is about a different application/process presumably reading information of the target one (Chrome/plugin in this case) which is stored in the given computer's memory.
A quite descriptive analogy would be forgetting your wallet somewhere vs. someone reading your mind to know where your wallet is. I am not implying that exploiting meltdown is as unlikely as reading someone's mind, but it doesn't seem too easy anyway (not sure though). Anyone wanting to share some insights into all this is welcome to a previous discussion about it.
Clarification just in case: regardless of the tremendously low quality (+ dishonesty; please, refer to the aforementioned repository including a doing-nothing simple file with 400+ stars in GitHub!!) of some of the available codes, the whole meltdown premise seems very difficult (if possible at all) to be exploited as far as one thing is knowing certain memory addresses and a completely different story is being able to actually retrieve information which is stored there. In any case, note that most of my experience is focused on the algorithm-developing side of things by eminently relying on managed languages. I have some low-levelish experience (in C), but knowing how everything is working at the memory-level is certainly not my strongest suit. Perhaps I missed something. As said, more than happy to get any kind of feedback or tangible references (= pretty much the opposite to a video showing random numbers, incredible claims without code/programs to support them or similar faith-based resources).
OK, look let's rewind. I think we were talking at crossed purposes and got pissed off at each other.
I didn't get pissed off by anything you said, I simply accepted that no worthy discussion was possible. I openly said that to you and you were the one getting pissed. This last post of yours reconfirms my original assumption: you are back to your let's-convince-everyone-that-they-have-to-like-what-i-do loop. Please, don't get offended and try to understand the ideas which I am explaining below these lines which aren't too difficult.
I shared here my opinion about Rust by clearly explaining the context (= new to the language, quick test with a small development together with other languages on which I had no experience either, quite experienced in different programming languages and used to move from one to the other, etc. BTW, nobody has asked me about that code which is written in quite a few different languages other than these 4 ones; if I was you, the first thing I would like to see is the code, isn't that all what should matter here?). You and most of other Rust-defenders (Rustaceans, I think that you call yourselves) didn't understand my intention and words within the right context and simply started to blindly defend the benefits of it, something which I wasn't asking and that doesn't even seem a sensible reaction to my original post. None of your arguments have even tried to address the main issues which I was criticising (= unfriendliness, rigidity, lack of adaptability, etc. in general making the programming experience unnecessarily difficult unlikely many other languages), just coming up excuses for it. You have simply tried to prove what is evidently impossible to be problem: that there is no better way to do things! There are tons of better ways! Just the other 3 languages I tried in this small experiment do things notable better on this front!
In my previous message, I saw a glimpse of sensitivity and tried to help you understand one last time. Your answer? Coming back to do exactly the same than you have been doing since the start: blindly defending something which I am not attacking and/or trying to convince me about what I don't care! The only sensible reply to someone saying that found whatever programming language (BTW, I cannot understand this intense feelings for a so abstract and saying-nothing reality like a programming language!! They are mere tools! If they don't behave as they should, just use a different one!! There are tons of them!!) unappealing for whatever reason is accepting that or, in case that you care about the opinion of that person, perform the corresponding changes. But why trying to convince me (well... this would have required sensible arguments; it has been mostly some kind of pushing, pressuring, bullying, attacking, trying to force, etc.) to like the language which you do?! How can you think that the normal reaction to someone saying "I don't like that" is "you have to like it"!! Why? Can you see in any of my comments to you or to anyone else even the slightest attempt to push anyone to like whatever or to stop liking what they do? You can only see things on the lines of "I like X", "I dislike Y" + some context references ("note that my background is Z").
Can you finally understand why I didn't want to continue this "conversation", why I temporarily thought that I could get through to you and why that last comment has confirmed my preliminary assumptions and that I will better not be talking to you (certainly not about your sacred bits like Rust)? I am not trying to criticise you, define your personality or even say that your behaviour is wrong (if you are happy and not hurting anyone, everything is fine with me), I am trying to help you understand what you don't seem to be able to see here: there is nothing for us to discuss. No hard feelings. I am simply not willing to be patient with certain attitudes. If you want to have any discussion about whatever issue by relying on what I consider basic requirements (properly
This has been weird... I have posted right now a reasonably big reply with conclusions after some tests/research which hasn't been stored. A bit tired I guess. I am not willing to re-write everything. The short summary is that I wasn't able to find a way for a process, supposed to only access a given address space (its regions are defined in /proc/PID/maps; this is the most similar thing I could find to your "base address"), to do anything with the memory allocated by another one. Regardless of the fact that certain highly sensitive, OS-accessible memory isn't properly managed, the question of how to access that memory remains. Even under ideal conditions (admin privileges, perfect information about the memory addresses and data types), a process running on the give OS can only access memory locations within its assigned range.
How can this be overcome? How can all these memory-dumps become useful? How could that famous-but-not-found-so-far app able to read passwords from Chrome be built? Even by having all the information regarding the memory location of the given strings, how could them be read by a random process? I think that this are all the main ideas which I wrote in that longer-&-now-lost post. If I misunderstood any bit or anyone knows about a ready-to-use sample delivering a tangible result, please let me know.
Well... your attitude in this post seems notably different. Sorry if I misinterpreted you or expressed myself poorly.
Regarding your "You seem to know nothing about the technical nature of Rust, nor its use in practice and yet you're arguing vociferously about it.", just want to clarify that I haven't ever hidden my limited knowledge about Rust. In fact, the whole point of my comment since the start was describing how unfriendly I found it as a newcomer (despite my relevant expertise and adaptability on the programming-language front). Also as highlighted in other comments (+ at least IMO, the most logical interpretation of my behaviour), I think that critics should be welcome or ignored; getting offended or not wanting to properly understand them doesn't seem to make too much sense. I have merely shared my honest and objective opinion which, ideally, might be useful to further improve on certain fronts. Even though I currently don't like Rust at all, I might change my opinion in the future; many other programming languages have gone through a relevant evolution.
Don't even bother. Rust zealots can't be reasoned with.
A true pity that these ideas can be (rightfully) applied to programming-/engineering-/scientific-related whatever.
because the password is stored in some easily guessable memory location
Not just easily guessable, exactly the same every time!!! What sounds quite weird! At least, by looking at what these codes are supposed to be doing, they are generating memory locations regardless of anything else including Chrome!! The underlying idea is that Chrome stores all the passwords (and only the passwords!) in the same memory locations (which might change from computer to computer or even after restarting it, but which are the same for all the running applications)!!! Lots of very weird assumptions, but well... these might be extremely faulty codes, not saying that this is a basic requirement for the referred bug (no idea though).
Another issue I didn't mention but which you correctly pointed out: the memory location has to be added to the base address of the given application, what represents an additional difficulty (+ finding out said base address). Easy? No instructions? Weirder and weirder! Anyway, I will give it a try in some hours and share my impressions.
Take any of the PoCs outputting memory. Set that start address to the base address of your target application (how to get this depends on the OS. In Linux you can look in /proc) or the kernel. Run the PoC, pipe the output through strings. Data will show up.
Let's see if I understand you correctly. Consider the following C code:
//the value of char1, a. //memory address where char1 is stored. //same value than char1, a. //same memory address than the one of char1.
char char1 = 'a';
printf("%c", char1);
printf("%p", &char1);
char* char2 = &char1;
printf("%c", *char2);
printf("%p", char2);
You can play around with the memory locations of all the variables (+ get their values) as much as you want within the same application. Now, if I print the value of the aforementioned memory location to a file and, while that program is still running, I execute a second program which reads that file and tries to get the value associated to that memory location, an error will happen because that memory address will not make any sense for that second program. But, due to this bug, there are cases where that situation can occur (reading certain memory location from a different application and getting the value stored there by that original application). Some of the listed codes generate a set of memory addresses with that "feature" which consequently can be read from any other application?! If I understand it correctly, it wouldn't be straightforward at all and would imply a ton of assumptions (why a variable is stored in exactly the same memory location? Why the given program, out of the tons of different possibilities, would be relying on exactly the approach allowing that? Is the type of that memory allocation always char? etc.); what makes the referred lack of instructions even weirder! Anyway, I might give it a shot in the afternoon and write here my impressions. Thanks for the explanation.
thousands of people around the world working hard on proving you wrong as we speak
I have so many enemies? Because of something I said? I can change if they want! LOL. Yes, I get your point.
If I could do it myself I would not be publishing my results here for you.
I understand that this is the case with these things (researchers + public work way behind the malicious activity), but there has been so much publicity this time! And, after looking at some of the codes posted in a comment above, my doubts are even stronger. Anyway, it was just out of curiosity as far as I don't consider myself or my computers a target of this kind of things (poor + cautious).
That was from a 5 second google search. I have only tested the top one myself but I know it works.
Thanks and sorry for having been so lazy myself. Anyway, I also looked at the first one and it seems to deliver (didn't run it, just read the docs and saw the video) pretty much the same than what I have seen in some other places: memory dumps (from in principle protected locations). This is kind of demonstrating what the bug is about, but not the real exploit I meant. What I meant with real exploit was an application which might actually be used to perform whatever potentially-dangerous action on my computer. Having access to protected memory isn't ideal, true; but how could all that be easily use to accomplish whatever goal? How could you convert those memory locations into ways to trick whatever software to behave against my intent? Having just a memory dump isn't too useful by itself.
Then, I took a look at the fourth one (with 482 stars!) which is a simple C file, with no instructions that, when executed, prints an a array of strings which might a song or something?! The readme says that it can read password from Chrome?! (by assuming that all the hidden fields are stored in the same way and in the same place in all the OSs, it might make sense but not in any other scenario. And why just Chrome?!). In any case, that code is just running the loop with the song, nothing else(!!).
Then, I looked at the second one which is also a C file but much more complex than the aforementioned sample. This time I cannot know immediately what it does, so I run it and it printed out something about it working and what seems memory locations. Again, no instructions no explanation and, at first sight, no idea how this is supposed to be reading passwords from anywhere. I think that I have now more doubts than before your post (thanks again, anyway)! If reading passwords from a browser is so easy why aren't they including a clear code/application with clear instructions? Or even worse: why all of them are saying that everything works fine, that it is very scary when their codes don't seem to be doing anything? Perhaps I am a bit tired now and am I missing something or what?
I am not saying that it is impossible to be exploited, but much more difficult than what so much advertisement seems to imply. Logically, I am more than ready to be proven wrong. Also I do think that all this should be eventually fixed, at least, under the most demanding/vulnerable conditions. Anyone willing to put together a small virus (not doing anything bad + source code, evidently) to prove me wrong?