karlchen wrote:
No need to panic, but a good reason
+ to update the AV definition files and do a full system scan
+ to upload any download to Virustotal first in the near future
+ keep in mind that there is not the one-and-only AV product which will always be right
I think in addition to those things, there is much more to be done by programmers. Using AV products to confirm anything is clean is not fully reliable. It's also much better to prevent infections in the first place than to clean them up later, possibly after we have given malicious code to our customers. AVs rarely detect very new viruses. This one shows that very well. According to McAfee it was out for many months, even a year, before AVs started to detect it.
http://www.avertlabs.com/research/blog/index.php/2009/08/19/induc-virus-abuses-delphi-compiler/
Programmers should avoid executing code from untrusted sources on their development systems. Basically almost everyone else is untrusted. It makes sense to also limit the access rights a virus could easily get. For example, do not use the Unix root or WindowsNT admin account to develop software, unless necessary, and don't give standard users write access to system files and other important files like SysConst.pas and SysConst.dcu that this virus infects. If you need to edit those files, you can always elevate to admin for that task. At any time, only have the minimal access rights you need to do your tasks, and no more. Principle of minimal privilege!
Viruses like this could easily be avoided by good security practices, and without the help of AVs. In this case AVs never gave alarms to people even when they were infected by this virus for months. AVs are imperfect like everything, so something more must be used.
