Botnets! Ever increasing Threat!!

[Guest]

[gibran]

[ at ] gibran: I'm not pushing heavy weights to a third party.
The problem is: If there is no such thing from a thrid party, people rather go unprotected than fighting pop-ups. You can't help people that don't understand and don't want to invest any energy to understand.
That's why I say: Make it noisefree or try to educate the masses. Both are nontrivial tasks but the latter seems to be a little harder to me.

I agree with your owerall view but not with the outcome. Both aspects are important and I think that a zero interaction security software is equally difficult goal to reach. It would be like to develop an artificial Intelligence.

Like burillo hinted there could be ways to leverage a cooperative approach to security I scattered few posts on the forum and I'm sure that many other aspects could be enhanced.

A community driven ruleset DB would prove no useful benefit over current Comodo safelist approach. Comodo staff has tools and skills to peek in software "black boxes" whereas the community usually cannot.
If such option will be restricted only to unknows (not yet safelisted apps) then there would be an high chance that malicious software will got many fake approvals before it will spread.
But a collaborative approach could improve community learning potential. So a way to share rulesets and to autenticate the source of an imported rule will provide further flexibility and enforce trust chains.

Did I say that softwares are like a bloack box? Are you fine with this? BTW that's why we need alerts As of now if an executable is signed we can add it to trusted vendors and V3 will automatically learn it.
But what about unsigned executables? What abut developers that cannot afford a SSL certificate?

You know, developers could be the only ones that have no issues when it comes to create rulesets for their softwares. What gives? also hackers could create rulesets for their malwares but I wonder if they are really motivated to make it clear what their malwares will do Anyway rulesets are not really suited for this task but a metalanguage to define an app behaviour will do. An interoperable standard could be created and we ssolve part of the issues.

If it is possible to outline an app behaviour before an app will run then a software could analyze such outline and output a security score, anyway it would be possible to read such behaviour in a human readable language and gain a better insight. So what we have there? A way to know in advance how an app will behave. We can block certain behaviours in advance. We can know if something that will occur was not declared in the outlined behaviour( an exploit?).

Then we have another chance. There are many security experts and advisories DB. A safe app could be vulnerable to exploits. So a way to learn about new vunerabilities and automatically tune the security software behaviour and take appropriate measures will further enhance the user experience.

This is somewhat a community isn't it?

[Burillo]

there already IS an app similar to one you described. It is called Security Task Manager or something like that... It gives a "security score" to the process based on code analysis. The only difference is that it "scores" already running processes.

[gibran]

there already IS an app similar to one you described. It is called Security Task Manager or something like that... It gives a "security score" to the process based on code analysis. The only difference is that it "scores" already running processes.

There is NOT

Heuristically based scores use a different approach. Safelisting use another approach too. A description of an app behaviour is something NEVER attempted.
Sure it would difficult to attain such thing but if there would be no architecture to support it this will never take place.

BTW it would be far easier to guess a security score from an app behaviour description than waiting for an alert or using heuristics.

[weaker]

[ at ]Burillo:
To automatically understand what a program does is still not solved, even when you have the source. It works for very small, simple programs but not for real software.

[Japo]

To automatically understand what a program does is still not solved, even when you have the source.

If it's already hard enough to debug a program written by yourself... And don't you think hackers put comments in their source code?

[Burillo]

well, real software actually does not tend to harm your computer...

[weaker]

I was just talking about complexity here.

[Japo]

Burrillo, take a look at this:

Code:

#define z printf
#define L(a,b) for(c=a;c<a+3;c++)z(x[b*!!(d&1<<c)],c+1)
#define R(a) z("\n\n\t");L(a,1);z("\n\t");L(a,2);z("\n\t");L(a,1)
char *x[]={"**... "," +===+"," | %d |"},n;int d,m[]={27,7,54,73,186,292,216,448,
432};p(){int c;R(6);R(3);R(0);}main() {srand (time(0));d=1+rand ()%511;p();do{z(
"\n\t\tmove ? ");do n=getche ()-'1';while(n<0||n>8);if(d&1<<n)d^=m[n];p();}while
(d&&(d==495)?!z("\n\n\t\tGoal!!!\n"):1);}

(From here.)It doesn't harm your computer, it's just a small console game. And it's the source code, nothing you can see when talking about malware except if you get into the programmers' home. And now imagine that it's at least a hundred times longer...

[gibran]

Burrillo, take a look at this:
...snip...
(From here.)It doesn't harm your computer, it's just a small console game. And it's the source code, nothing you can see when talking about malware except if you get into the programmers' home. And now imagine that it's at least a hundred times longer...

Yep that's true. Even if the source code is written properly and it's well commented there would be still chances of exploits occuriing.
That's why focusing on a behavioural outline could prove more useful. Nowaday programming is very difficult as you have to account for privileges, rights and so on.
LUA (Limited User Account) compliant apps are not widespread and many apps require admin privileges.
Looking at V3 HIPS alerts I see many apps using leaktest-like functions.

For example firefox has direct keyboard access + direct video access + internet connection privileges. A keylogger that takes screenshots and send them over the internet require the same privileges. Who am I to decide if FF is safe and another app is not? A developer could decide if certain functions are really needed and create a software that will not break if some user want to disable them. Anyway a behavioural outline should make clear what an app need to work. It comes to mind what directories need to dwell into or what unowned registry keys need to read or to write.

A behavioural outline could be regarded like a source code. This imply if the standard is not well developed it will be useless.

But I would be fine If I can know If an app need to write only in Documents folder (for example),in its profile directory and temp directory.

But on a related side there is another thing that come to mind.
When Windows NT executable format was developed I read a MS representative interview that the list of an app needed functions was like it was written on stone.
That was true only for a period of time. as of now a way to enforce those words could still have its uses.

[Burillo]

from what i read here i see that behaviour analysis described above is almost impossible... especially since there are growing numbers of crypted malware.

[gibran]

from what i read here i see that behaviour analysis described above is almost impossible... especially since there are growing numbers of crypted malware.

That's why an application behaviour metalanguage could prove useful. To a basic level it could be considered like an application HIPS ruleset but it should be more standardized and abstract than this so any hips could imply its ruleset. In the end you have something to look at before the app will run. Privileges can be reduced and the HIPS will enforce Users choices even if the app was encrypted.

[Burillo]

well it's pretty promising idea, still - very hard to implement... Yes, you can show the user that the program is going to load some UI dlls, install a tray icon etc. but still... The first thing is software vulnerabilities. A typical-looking code could be an exploit, and i'm not quite sure that this "metalanguage" could inform the user like  "May i have your attention please? You see, trojan.exe is going to exploit winword's vulnerability and infect your machine, should i allow?")))) The second thing - some unusual and undocumented APIs. As far as i know most malware don't use standard APIs but target vulnerabilities or undocumented functions. And of course, apart from that, it is pretty difficult to fully describe a whole sh-tload of Windows APIs - if even M$'s own MFC library doesn't cover it all - in fact, a half or even less than that...

[gibran]

well it's pretty promising idea, still - very hard to implement... Yes, you can show the user that the program is going to load some UI dlls, install a tray icon etc. but still... The first thing is software vulnerabilities. A typical-looking code could be an exploit, and i'm not quite sure that this "metalanguage" could inform the user like  "May i have your attention please? You see, trojan.exe is going to exploit winword's vulnerability and infect your machine, should i allow?")))) The second thing - some unusual and undocumented APIs. As far as i know most malware don't use standard APIs but target vulnerabilities or undocumented functions. And of course, apart from that, it is pretty difficult to fully describe a whole sh-tload of Windows APIs - if even M$'s own MFC library doesn't cover it all - in fact, a half or even less than that...

I addressed these very concerns in my first post about this topic.

[venom_zx]

my opinion:

i think this problem has already been addressed for a long time.
generally the problem described is...

- can an application be trusted?

i think in even more general sense the question is:

- "do i know this program"

if you know the program then you know it can be trusted.
like i said i think this problem of authentication has been addressed long ago.

( cryptographic )signatures
you (comodo) even do offer such a system too! :p (saw it on the main page: Code Signing)

Pros:
the software author could sign the software using the data that makes up the program. and the user (or other software like comodo firewall) could check whether the signature is correct.  then it would be a breeze to recognize the program and thus allow it. i wonder if that could get rid of all popups for most people. then the user could be asked about whether she trusts "some_known_name" and that would be that. instead of giving all the technical details of what its exactly trying to do.

of course virus authors can also sign their virusses. but the user should know that its not the software they run.

Cons:
- every author has to sign their software. preferrably all using one system. (probably the biggest show stopper)
- you have to trust the user in knowing which software they run.
- and something would have to be done about the spoofing by look alike author/software names

so it is close to the idea of you guys.

i think comodo firewall is quite good and it's free too so even better. maybe this will sound demanding but Code Signing would really have to catch on though, mabye even be free to catch on.

that's my opinion

venom_zx

[gibran]

venom_zx what about a signed executable that suddenly develop "new abilities" ? 

Relying only on code signing is not a solution. If a signed executable is exploitable the beavioiur will be more relevant.

Also if we regard the behavioral approach not all behaviour of an app could be considered safe by every user (each one has his preference or security needs).
On a sidenote if there is a way to score the behavioural security of an app or even to know that an app from a specific developers needs only few efforts to be hardened then code signing makes all apps from that developer easily recognizeable.

I guess that a "behavioural fingerprinting" could be regarded also as an extension of code signing certs.

[Tags:]