I read about instruction set randomization in modern processors where a processor randomizes the instruction sets to avoid code injection attacks. Actually, Wikipedia explanation is not clear to me. Kindly, can someone explain the process of it in a clear way? Is there a key involved?
The idea of instruction randomization is to avoid code injection attacks. Say for example there is some vulnerable code that the attacker wishes to execute and all s/he has to do is to transfer the program control to the beginning of that code block. In a non-protected environment once the control is transferred, the CPU will begin the execution of the code as it cannot distinguish the proper code from the vulnerable code. One "simple" thing you can do to prevent such attacks is to use some encryption (with a key) to the proper machine code which the attacker has no idea of. So in the decode stage, the proper code will first get decrypted and then decoded. Since the attacker does not know the key that is used to encrypt the proper code, their code wont succeed the decryption stage, hence wont get executed.
Related
This question already has an answer here:
Secure erasing of password from memory in Ruby
(1 answer)
Closed 2 years ago.
I have a use case where I need to dispose of some data the very moment I don't need it anymore, for security reasons.
I am writing a server in Ruby that deals with logins and passwords. I use BCrypt to store passwords in my database. My server receives the password, makes a bcrypt hash out of it, and then doesn't use the original password anymore.
I know of a kind of cyberattacks that involves stealing data right from RAM, and I am concerned that an attacker might steal a user's password in raw string form in the period of time that the password is still in memory. I am not sure if simply using password_in_string_form = nil would be enough.
I want to nullify the variable that holds the user's password the moment I am done with it. By nullify I mean something akin to using /dev/null to fill something with zeroes. The end goal is irreversible destruction of data.
I am not sure if simply using password_in_string_form = nil would be enough.
No, it would not be enough. The object might or might not be garbage collected immediately, and even if it was, that does not cause the contents to be erased from memory.
However, unless they have been frozen, Ruby strings are mutable. Thus, as long as you do not freeze the password string, you can replace its contents with zeroes, or random characters, or whatever before you let go of it. In particular, this should work, subject a few provisos, covered later:
(0 ... password_in_string_form.length).each do |i|
password_in_string_form[i] = ' '
end
But care needs to be exercised, for this approach, which may seem more idomatic, does not work:
# SURPRISE! This does not reliably remove the password from memory!
password_in_string_form.replace(' ' * password_in_string_form.length)
Rather than updating the target string's contents in-place, replace() releases the contents to Ruby's internal allocator (which does not modify them), and chooses a strategy for the new contents based on details of the replacement.
The difference in effect between those two approaches should be a big warning flag for you, however. Ruby is a pretty high-level language. It gives you a lot of leverage, but at the cost of control over fine details, such as whether and how long data are retained in memory.
And that brings me to the provisos. Here are the main ones:
As you handle the password string, you must take care to avoid making copies of it or of any part of it, or else to capture all the copies and trash them, too. That will take some discipline and attention to detail, because it is very easy to make such copies.
Trashing the password string itself may not be enough to achieve your objective. You also need to trash any other copies of password in memory, such as from upstream of isolating the password string. If yours is a web application, for instance, that would include the contents of the HTTP request in which the password was delivered to your application, and probably more strings derived from it than just the isolated password string. Similar applies to other kinds of applications.
passwords may not be the only thing you need to protect. If an adversary is in a position where they can steal passwords from the host machine's memory, then they are also in position to steal the sensitive data that users access after logging in.
For these and other reasons, if the security requirements for your server dictate that in-memory copies of user passwords be destroyed as soon as they are no longer needed, then (pure) Ruby may not be an appropriate implementation language.
On the other hand, if an adversary obtains sufficient access to scrape passwords from memory / swap, then it's probably game over already. At minimum, they will have access to everything your application can access. That doesn't make the passwords altogether moot, but you should take it into consideration in your evaluation of how much effort to devote to this issue.
This is not possible in Ruby.
You will have to write some code specific to each implementation (Opal, TruffleRuby, JRuby, Rubinius, MRuby, YARV, etc.) to ensure that. Depending on the implementation, it may not even be possible to do inside of the managed memory of the implementation at all, without having a separate piece of memory that you manage yourself.
I.e. you will probably need to have some tiny piece of native code that manages its own tiny piece of native memory and injects it into your Ruby program.
I'm doing this as a personal project, I want to make a visualizer for this data. but the first step is getting the data.
My current plan is to
make my program debug the target process step through it
each step record the EIP from every thread's context within the target process
construct the memory address the instruction uses from the context and store it.
Is there an easier or built in way to do this?
Have a look at Intel PIN for dynamic binary instrumentation / running a hook for every load / store instruction. intel-pin
Instead of actually single-stepping in a debugger (extremely slow), it does binary-to-binary JIT to add calls to your hooks.
https://software.intel.com/sites/landingpage/pintool/docs/81205/Pin/html/index.html
Honestly the best way to do this is probably instrumentation like Peter suggested, depending on your goals. Have you ever ran a script that stepped through code in a debugger? Even automated it's incredibly slow. The only other alternative I see is page faults, which would also be incredibly slow but should still be faster than single step. Basically you make every page not in the currently executing section inaccessible. Any RW access outside of executing code will trigger an exception where you can log details and handle it. Of course this has a lot of flaws -- you can't detect RW in the current page, it's still going to be slow, it can get complicated such as handling page execution transfers, multiple threads, etc. The final possible solution I have would be to have a timer interrupt that checks RW access for each page. This would be incredibly fast and, although it would provide no specific addresses, it would give you an aggregate of pages written to and read from. I'm actually not entirely sure off the top of my head if Windows exposes that information already and I'm also not sure if there's a reliable way to guarantee your timers would get hit before the kernel clears those bits.
My text book doesn't seem to answer this question, just that it has to 'decode' the instruction, so it doesn't answer how it knows it has an instruction in the first place.
My research into this gives me possibly two answers:
1) It can't because both data and instructions look the same in memory, so it has to use the Program Counter to load the next instruction which may or may not fetch the next data it needs through addressing.
2) Something something opcodes something....
I'm trying to figure out a clearly understandable way of explaining this so I know I can understand it.
The processor fetches and decodes whatever memory is pointed at by the Program Counter.
The decoder can throw an "invalid instruction" exception if it does not understand the instruction. It will then jump to the exception handler (i.e., the OS), which will try to make sense of the invalid instruction. Often, it may just be an unsupported instruction that can be handled in software (e.g., floating point divide), and then execution can resume from where it had left off.
However, if it's a true invalid instruction, then the program will error out with some sort of exception/crash ("Illegal Instruction" on x86 I believe).
One technique to help separate code from data is to put them on different "pages" in virtual memory. The OS can then mark the page that the code sits on as "read-only". In this manner, a program trying to overwrite code will throw an exception. Some systems allow even more protection, such as "Fault on Execute" - throw an exception if you try to execute code on this page (More info here: http://www.tldp.org/LDP/tlk/mm/memory.html).
Things can get a bit weird though in that some code actually does need to be "modifiable" by the program (aka, "self modifying code"). This is made difficult because you typically have separate instruction caches and data caches. Typically, the instruction cache is oblivious to the world around it - it will have no idea that somebody has written new data to the addresses it contains. For some platforms, it is the job of the programmer to flush the i-cache after modifying the instruction data, so that the i-cache can refetch the updated instructions.
In the end though, it's the job of the programmer/compiler to make sure that the PC never jumps to any address that isn't code.
(Of course, malicious users will of course try to get the PC to jump to their bad code, but I'll save stack buffer overflow attacks for another post.)
I'd like to write some simple code that helps to determine if some instructions have been executed in the intended order client-side. This is to make things difficult for anyone wishing to alter behaviour by editing byte code. For example, using a JMP so some instructions are never executed. I'm a bit short on ideas though.
To check if the last two instructions have been run in the correct order something simple like this could be used (pseudo code):
// Variables initialized by server
int lastInt;
// Monitored at regular intervals
// Saves using callback which could be tampered with
boolean bSomethingFishyHere;
int array[20]
...
execute( array[5], doStuff1() )
execute( array[6], doStuff2() )
...
// This could be tested remotely with all combinations of values possible
execute( int i, boolean b ){
if( lastInt >= i ){
bSomethingFishyHere = true;
}
lastInt = i;
}
I'm at a loss at to what approach could be used to verify if all instructions have been run in the correct order though. Maybe I could add an array and have it populated by the server with some randomly ascending numbers or use some sort checksum. What are your suggestions?
The problem is, that no matter what kind of book-keeping you do, a malicious user can always do the same book-keeping, but skip over the actual doing stuff. If you can do it, so can they. You can rely on external mechanisms, like code-signing to ensure that your executable hasn't been tampered with and CPU protections to prevent on-the-fly modification of the code in memory. But in that case you're only as secure as the platform you're running on.
I'm assuming this is some sort of copy-protection scheme. (If not, feel free to correct me, and you might get some better, more applicable advice). There isn't a fool-proof way to prevent someone from running your software, but you can license an existing scheme where the vendor has already put enough effort into it, that it's not worth it for an attacker to bother, for the most part.
The one way that is pretty much fool-proof, is if you control the code. Run the real meat of the code on your servers, and provide some sort of front end remote client.
This is just to patch some holes in an fps shooter. The designers of the game left some temporary variables that can be changed in the console. Some of them are harmless but others like Texture transparent=true are abusive. What I'm aiming for is to redesign an existing modification so most of the code is on the server as you suggest. The variables in question are set in the "world" that is mimicked by the client. Ultimately, I'm planning to extend some classes so they ignore them and just need to monitor values where this isn't possible.
If you do want a short-term patch, a more practical approach (than the one you are looking at) would to send encrypted bytecodes to the client and using a special classloader to decrypt them on the fly. Beware however that it wouldn't be that difficult for a hacker to reverse engineer the classloader, get hold of the client-side bytecodes, and modify them to install the cheats.
So my advice is that any client-side "patch" to stop users tampering with the bytecodes is never going to be hack-proof. Skip that idea, and go straight to your long term solution of rearchitecting the game so that it is not necessary to trust that the client-side code plays by the rules.
I've noticed (on Win32 at least) that in executables, code sections (.text) have the "read" access bit set, as well as the "execute" access bit. Are there any bonafide legit reasons for code to be reading itself instead of executing itself? I thought this was what other sections were for (such as .rdata).
(Specifically, I'm talking about IMAGE_SCN_MEM_READ.)
IMAGE_SCN_MEM_EXECUTE |IMAGE_SCN_MEM_READ are mapped into memory as PAGE_EXECUTE_READ, which is equivalent to PAGE_EXECUTE_WRITECOPY. This is needed to enable copy-on-write access. Copy-on-write means that any attempts to modify the page results in a new, process-private copy of the page being created.
There are a few different reasons for needing write-copy:
Code that needs to be relocated by the loader must have this set so that the loader can do the fix-ups. This is very common.
Sections that have code and data in single section would need this as well, to enable modifying process globals. Code & data in a single section can save space, and possibly improve locality by having code and the globals the code uses being on the same page.
Code that attempts to modify itself. I believe this is fairly rare.
Compile-time constants, particularly for long long or double values, are often loaded with a mov register, address statement from the code segment.
The one example I can think of for a reason to read code is to allow for self modifying code. Code must necessarily be able to read itself in order to be self modifying.
Also consider the opposite side. What advantage is gained from disallowing code from reading itself? I struggled for a bit on this one but I can see no advantage gained from doing so.