Who’s guilty ?

Both Firefox and Windows are to blame for.

Firefox

Firefox simplifies the process of finding the target function PR_Write as it is inside a dll, compromising the security of the web browser.

Windows

Windows lets our malicious FormGrabber interfere with the normal Firefox’s workflow without asking any questions. It lets our process execute code within Firefox’s Virtual Address Space and more importantly it lets our malicious process change segments of Firefox code.

Am I safer with other browsers ?

I wouldn’t go for Internet Explorer if I were you as it might be even easier to hack. There should be no need to do over-complicated assembler magic to hook to a function, the simple SetWindowHookEx API would suffice. In the case that method ceased to work, the dll hack presented in this article would still function as IE uses a dll for sending POST data through the net.

Chrome is a bit safer, as the code that communicates to the net is hard-coded right into the main process. So there is no easy way of finding where exactly the “interesting” function is, except of course if you know which version of chrome the user is running.

I don’t currently have any information about other web browsers. May be you can share your knowledge ?

What should we do about it ?

I believe Firefox should stop using dlls where critical information is being used. Unfortunately this won’t necessarily make Firefox safer, but will at least protect your data to some degree.

What should really be changed is the way windows works.

A lot of work has been done to ship a competent Firewall in every Windows distribution since XP was launched. Unfortunately, the default Windows' firewall rules won’t block any outgoing connections. The fact that not only form grabbers but most malware connects to the internet is enough of a reason to change how the firewalls default rules work. The user should create a white list of processes that are allowed to connect to distant servers, thus reducing the impact of security threats. Unfortunately this change might not be feasible for existing installations, but should be considered to be the default behavior in the coming Windows 8 release. Yet, blocking untrustworthy connections might not even work as the malicious code has been injected into Firefox. Therefore, the one connecting to the remote evil server is the trusted Firefox process and not the original malicious process.

That alone would not be enough. Processes should not be able to modify each other, except if the user granted them the permission to do so. More precisely, unrelated processes should not be able to change memory protection states such as in PAGE_EXECUTE_READWRITE and they should not be able to inject code to each other.

In the meantime, you could either grab a decent firewall, change your windows firewall settings or pray everything goes well. And more importantly : NEVER RUN BINARY CODE FROM SOURCES YOU DON’T TRUST.