suggested reading
according to the article:
this technique has always troubled me as it would seem when an app program loads executable code into its own address space that code could become vulnerable. as I understand it the memory protection model in 80386 and above provides various protections,-- read only pages, pages for executable code, -- ...?As Silon (and Zeus, and SpyeEye) before it, Tilon performs Man-in-the-Browser attacks by injecting itself into the browser and thus gaining control over the traffic going to and from it, as well as the capacity to capture all form submissions from the browser to the web server. The researchers thought that the same cyber gang was behind the creation of both Silon and Tilon.
read only pages are fine but how many programmers write re-entrant code? I think msft has attempted to defeat this problem with their ASLR and other whac-a-mole patches but it leaves me wondering -- how to protect the executable code in an address space which is taking in raw data
UPDATE
an interesting article on Wired this morning discusses exploits in application code -- particularly browsers . it is interesting to reflect that in Linux -- if you simply close the browser and re-start it -- you should have a clean copy as the Linux Kernel should prevent any exploit of the user-land browser code from corrupting the library binary code from which the browser is launched.
UPDATE
this article on MSFT EMET reveals the massive effort being made to protect "user land" executable code in msft systems from exploitation. the real concern would be: can the attacker obtain "privilege escalation" -- i.e. get out of his sand-box -- once he has code execution? he would need privilege escalation to attack the host o/s and I don't see that as a real threat in the Linux environment
UPDATE
EMET updated and hardened ( whac-a-mole game continued, as usual )
one might wonder why such measures seem to be needed. as a programmer I control the path that the program follows as well as what data moves from where to where. -- until I make a mistake. Evidently hackers find ways where they can take advantage of mistakes and somehow manage to get executable code into the application memory and secondly manage this in such a way that the path of execution goes into the bad code. this "return oriented programming" seems to be a recent means of doing that; "buffer overflow" having been used extensively as well. but these are programmer errors. but,--- programmer errors are expected in app. programs. the thing that is not acceptable is for such errors to corrupt the host o/s. which, I think, is the essential difference between Linux and MSFT.
