>>>>> paramter validation or parsing or something - but I just can't see at
>>>>> this stage how it's useful, given that I've been unable to get any of
>>>>> these problems to affect the actual antivirus process running in the
>>>>> system account (that's the one that does the actual work), without
>>>>> administrator privileges (and then as indicated, it's not much of an
>>>>> exploit if it requires administrative privileges to pull off.)
>>>>>
>>>>> Regards,
>>>>> Jon.
>>>>>
>>
>>> paramter validation or parsing or something - but I just can't see at
>>> this stage how it's useful, given that I've been unable to get any of
>>> these problems to affect the actual antivirus process running in the
>>> system account (that's the one that does the actual work), without
>>> administrator privileges (and then as indicated, it's not much of an
>>> exploit if it requires administrative privileges to pull off.)
>>>
>>> Regards,
>>> Jon.
>>>
I didn't analyze Linux or BSD threats, but my gut feeling puts them at
the same level or even higher.
With 86% or more of the past threats requiring social engineering to
pull off, we can safely say the "future" you state below is here now.
Now, what is interesting is that any exploit requiring social
engineering to work has so far been less of a problem than the vast
majority of "remote buffer overflow" exploits like the Blaster and SQL
worms. Social engineering-required malware still works, and works well,
Even if it did work, the user would have to submit the form with the username or password fields containing the exploit code rather then enter their own information.
Pretty unlikely to pull off.
Regardless I talked to the developers and any potential issue will be fixed in v2.2.13 which is scheduled to be released before August 25th 2008.
>
> I didn't analyze Linux or BSD threats, but my gut feeling puts them at
> the same level or even higher.
>
> With 86% or more of the past threats requiring social engineering to
> pull off, we can safely say the "future" you state below is here now.
>
> Now, what is interesting is that any exploit requiring social
> engineering to work has so far been less of a problem than the vast
> majority of "remote buffer overflow" exploits like the Blaster and SQL
> worms. Social engineering-required malware still works, and works
vulnerabilities by CVE number and MS number (where it exists). I did
not care about whether it was trivial to exploit or hard to exploit.
Per a report the Microsoft Security Response Center (MSRC) released
recently, exploits are trending to become less trivial to exploit, but
not incredibly so. My simple analysis was a very crude, binary analysis.
If the user had to click one thing or ten things to pull off the
exploit, I called it client-side.
I mostly agree, "If I can get you to run my malicious program, it is
always game over" and not always a "security problem", but it is the
reality a computer security professional has to manage, whether we like
>>>> paramter validation or parsing or something - but I just can't see at
>>>> this stage how it's useful, given that I've been unable to get any of
>>>> these problems to affect the actual antivirus process running in the
>>>> system account (that's the one that does the actual work), without
>>>> administrator privileges (and then as indicated, it's not much of an
>>>> exploit if it requires administrative privileges to pull off.)
>>>>
>>>> Regards,
>>>> Jon.
>>>>
>
