What if you were able to get these sorts of email addresses for a temporary amount of time. Say you have a UI where you can specify a duration for the temporary email address that is generated on your behalf. Also the UI allows you to request an email address that was not time limited. When you were through with the transaction you could go back to the UI and disable that one. The email provider could limit the number of temporary addresses you have open at any one time to a small number to encourage you to remove the ones where your transaction was completed. (Also to limit abuse of the system.)
As a concrete example imagine that your name was John Doe and you are ordering some widgets from foo.com and your email service provider is bar.com. You have a UI that asks for the following which you might fill-in something like this:
Description: Buying widgets From: foo.com Duration: open ended
You might get a temporary email address to use something like this:
john.doe-buying.wid-foo.com-fhl9s4q1@bar.com
The UI would list your temporary email addresses with the full descriptions and expiration dates to make it easier for you to manage them. The last eight charaters are some sort of one time hash that is likely different for each temporary email address that you create and difficult to predict from the prior hashes. Most of the work in generating the temporary email addresses could be done on your client with the server verifying that you maintain no more than the maximum number of addresses that you are allowed.
I do not know about other people's experiences but these kinds of questions were not the kind I was presented with when interviewing for a job at Microsoft some many years ago. I was applying for software positions so that may have had something to do with it. I did get an offer so I must have done well enough in the process to have seen all of the successful candidate path.
The interview process was a grueling four day affair. With one full day of intense interview and some time off to explore the Redmond area (at least that is what I did with a free evening and one mostly free day). But even in the off-time there were interviews because HR scheduled lunches and dinners with employees for me. There the questions were mixed between very technical and personal. I would say that when not asking technical questions the interviewers were very interested in finding out how passionate I was about writing software and how I felt about working together with others.
But most often questions were _very_technical and I was expected to write C++ on the spot on white boards, notepads, or napkins in how I would solve a particulr problem. They were also very interested in the thought process that I used to arrive at a solution. I even got a problem that was genuinely impossible and after working on it for a while I started to figure that out. The interviewer knew this of course and I had to prove it to him that this was the case. Then I had to restrict the problem and solve that. I think that that was a novel type of question to ask. First, if I actually wrote some code that I claimed was correct, that would indicate very poorly on me. If I did not realize that the problem was not able to be solved as presented, then that would not be good either. Once the problem was identified, could I figure out a way to state a restricted similar problem that was indeed solvable? Also, I am sure that the interviewer was trying to judge my reaction. Did I reactly logically or did I just get frustrated and confused.
Thrown into the bag of questions, there were also some 'vision' questions. What did I see the future of computing to be like. I did not have any mind teaser questions like those in the article. The vast majority of the questions were very technical, answers were expected in C++, and were stated as practical problems that you might expect to have to solve when working on an OS.
It is clear from gems like this from the article that the reporter was confused so that it is impossible from the article itself to really undrestand how the three approaches would work:
"An overflow exploit generally works when an attacker sends a program requesting too much information. The data usually includes two components: one that crashes the application and one that's either a program or a memory address that points to a program that the attacker would like to run. When the application crashes due to the first component, the operating system will execute the second.
It is important to point out that this looks to be yet another in the attempts at making buffer over flow exploits difficult yet not quite impossible. Once you put return addresses on the stack (the same stack with an over flow) an exploit can jump to any place it likes in text even without an executable stack.
The details about the tag around import addresses and the random stack offsets could make exploits _very_ difficult. If the base of the stack is random from one invocation of the program to the next that does not give much more once you cannot execute on the stack so it is probably more than that. Also if the tag around important addresses (say the address of the buffer to system(3C)) incorpates randomness from one invocation of the program to the next then it would be hard to over flow a buffer and exploit it.
In any case even if you had a sytem where a buffer over flow could not be exploited to run arbitrary code but almost any random junk will still crash the broken prorgam, that does not do much to prevent DoS now does it.
Regarding the 2G/2G split. Yes it is common for the OS to split the virtual address space in such ways. Most have some way to tune it to say 1G/3G for example.
This FreeBSD work allows the kernel to put physical pages from memory beyond 4G behind virtual pages within the 4GB VA space. It does not allow an application to address more than 4GB for example. Some OS's allow you to move a window around in your VA space to deal with more than 4GB of data. For example on solaris_x86 xmemfs/mmap can be used for such a purpose.
Slashdot Mirror
What if you were able to get these sorts of email addresses for a temporary amount of time. Say you have a UI where you can specify a duration for the temporary email address that is generated on your behalf. Also the UI allows you to request an email address that was not time limited. When you were through with the transaction you could go back to the UI and disable that one. The email provider could limit the number of temporary addresses you have open at any one time to a small number to encourage you to remove the ones where your transaction was completed. (Also to limit abuse of the system.)
As a concrete example imagine that your name was John Doe and you are ordering some widgets from foo.com and your email service provider is bar.com. You have a UI that asks for the following which you might fill-in something like this:
Description: Buying widgets
From: foo.com
Duration: open ended
You might get a temporary email address to use something like this:
john.doe-buying.wid-foo.com-fhl9s4q1@bar.com
The UI would list your temporary email addresses with the full descriptions and expiration dates to make it easier for you to manage them. The last eight charaters are some sort of one time hash that is likely different for each temporary email address that you create and difficult to predict from the prior hashes. Most of the work in generating the temporary email addresses could be done on your client with the server verifying that you maintain no more than the maximum number of addresses that you are allowed.
I do not know about other people's experiences but these kinds of questions were not the kind I was presented with when interviewing for a job at Microsoft some many years ago. I was applying for software positions so that may have had something to do with it. I did get an offer so I must have done well enough in the process to have seen all of the successful candidate path.
The interview process was a grueling four day affair. With one full day of intense interview and some time off to explore the Redmond area (at least that is what I did with a free evening and one mostly free day). But even in the off-time there were interviews because HR scheduled lunches and dinners with employees for me. There the questions were mixed between very technical and personal. I would say that when not asking technical questions the interviewers were very interested in finding out how passionate I was about writing software and how I felt about working together with others.
But most often questions were _very_technical and I was expected to write C++ on the spot on white boards, notepads, or napkins in how I would solve a particulr problem. They were also very interested in the thought process that I used to arrive at a solution. I even got a problem that was genuinely impossible and after working on it for a while I started to figure that out. The interviewer knew this of course and I had to prove it to him that this was the case. Then I had to restrict the problem and solve that. I think that that was a novel type of question to ask. First, if I actually wrote some code that I claimed was correct, that would indicate very poorly on me. If I did not realize that the problem was not able to be solved as presented, then that would not be good either. Once the problem was identified, could I figure out a way to state a restricted similar problem that was indeed solvable? Also, I am sure that the interviewer was trying to judge my reaction. Did I reactly logically or did I just get frustrated and confused.
Thrown into the bag of questions, there were also some 'vision' questions. What did I see the future of computing to be like. I did not have any mind teaser questions like those in the article. The vast majority of the questions were very technical, answers were expected in C++, and were stated as practical problems that you might expect to have to solve when working on an OS.
It is clear from gems like this from the article that the reporter was confused so that it is impossible from the article itself to really undrestand how the three approaches would work:
"An overflow exploit generally works when an attacker sends a program requesting too much information. The data usually includes two components: one that crashes the application and one that's either a program or a memory address that points to a program that the attacker would like to run. When the application crashes due to the first component, the operating system will execute the second.
It is important to point out that this looks to be yet another in the attempts at making buffer over flow exploits difficult yet not quite impossible. Once you put return addresses on the stack (the same stack with an over flow) an exploit can jump to any place it likes in text even without an executable stack.
The details about the tag around import addresses and the random stack offsets could make exploits _very_ difficult. If the base of the stack is random from one invocation of the program to the next that does not give much more once you cannot execute on the stack so it is probably more than that. Also if the tag around important addresses (say the address of the buffer to system(3C)) incorpates randomness from one invocation of the program to the next then it would be hard to over flow a buffer and exploit it.
In any case even if you had a sytem where a buffer over flow could not be exploited to run arbitrary code but almost any random junk will still crash the broken prorgam, that does not do much to prevent DoS now does it.
Regarding the 2G/2G split. Yes it is common for the OS to split the virtual address space in such ways. Most have some way to tune it to say 1G/3G for example.
This FreeBSD work allows the kernel to put physical pages from memory beyond 4G behind virtual pages within the 4GB VA space. It does not allow an application to address more than 4GB for example. Some OS's allow you to move a window around in your VA space to deal with more than 4GB of data. For example on solaris_x86 xmemfs/mmap can be used for such a purpose.