61–70 of 100 posts
We just need a better sandboxing environment and individual permissions per excitable i.e. "Can this excitable connect to blah blah up?" , "can this program read outside of its sandbox folder?" When you don't root your android or iPhone they handle it a lot better than desktop operating systems.
Earlier quoted context omitted.
That's the beauty of it. Take the keystrokes example you gave. Run it. Allow it to monitor your keystrokes (by clicking "Allow" when it's doing stuff related to that). Allow it to create the file logging your keystrokes, if you want (granting it write only access when the dialog box comes up). But after you have toyed with it, you might stop it at the point when it attempts to read from that file, in order to transmi…
Isn't it dangerous to assume all malicious programs will use scratch files before communicating across the network? Won't you miss programs that use purely in-memory structures?
Earlier quoted context omitted.
That's the beauty of it. Take the keystrokes example you gave. Run it. Allow it to monitor your keystrokes (by clicking "Allow" when it's doing stuff related to that). Allow it to create the file logging your keystrokes, if you want (granting it write only access when the dialog box comes up). But after you have toyed with it, you might stop it at the point when it attempts to read from that file, in order to transmi…
Would you be interested in making a linux version of this?
Earlier quoted context omitted.
> What is malware? Is it a program that does something a user doesn't want? OS X Sandboxing seems to have the right idea: Instead of worrying about what the user doesn't want, do only what the user WANTS. Basically, sandboxed apps don't have access to files and folders other than the ones that the user explicitly chooses in an Open/Save dialog. It's a surprisingly nag-free opt-in mechanism that "just works." After th…
Re: OS nags...Windows is the worst IMO since UAC basically just asks ~it looks like you're trying to do a thing, are you sure you want to do that thing? The "open this program FROM THE INTERNET????" nag on OSX and Win are also pretty pointless. I've never not clicked yes, but there's not an easy way to disable this. It looks like it CAN be disabled with registry tweaks or GPEdit: http://www.sevenforums.com/tutorials/…
Earlier quoted context omitted.
No, this is not surprising at all. It's impossible to determine whether software is malicious or not (Rice's theorem). Antivirus software only reliably detects code that is identical to known malicious software.
That's not true - there's heurystic analysis techniques, generic signature detection etc. Of course they may not meet your definition of "reliably"
You're not secure until you whitelist. And even that's not a guarantee; it's a necessary but sufficient condition. But systems which do not run signed, whitelisted code from boot time forward are as good as pwnt.
> You're not secure until you whitelist. No, a whitelist isn't good enough. You can't anticipate an exhaustive list of the programs the user will want to run. What you can do, however, is enforce a policy by which programs are required to provide machine-checkable evidence, also known as proof-carrying code [ https://en.wikipedia.org/wiki/Proof-carrying_code ], that they respect the system's safety policy. > it's a n…
Earlier quoted context omitted.
No, this is not surprising at all. It's impossible to determine whether software is malicious or not (Rice's theorem). Antivirus software only reliably detects code that is identical to known malicious software.
> It's impossible to determine whether software is malicious or not (Rice's theorem). Which is why proof-carrying code [ https://en.wikipedia.org/wiki/Proof-carrying_code ] is a good idea: the onus ought to be on the programmer to provide (machine-checkable) evidence that their program is safe to use, for whatever notion of “safe” might make sense in your system.
Better route was started in Burrough's where you pick a language good at correct programs and carefully design a safe machine around it. Same with System/38, SAFE (crash-safe.org) for functional, and Cambrige's CHERI for C language. The fundamentals work as advertised along with ability to enforce arbitrary security policies. Then design and security stuff are built on that. Only thing known to work consistently to any degree of success.
On COTS hardware, separation kernels and compiler transforms on legacy code are about best that we can do.
So after the program is actually compiled into binary code do the resulting instructions become so simple (and so fundamental to the operation of programs) that any attempt to write a heuristics rule to stop this technique would break thousands of programs or are heuristics just so inherently shitty that this technique works? Because I would still think that this line here: void *exec = VirtualAlloc(0, sizeof c, MEM_…
At VirusTotal we are tired of repeating that the service was not designed as a tool to perform antivirus comparative analyses, but as a tool that checks suspicious samples with several antivirus solutions and helps antivirus labs by forwarding them the malware they fail to detect. Those who use VirusTotal to perform antivirus comparative analyses should know that they are making many implicit errors in their methodology, the most obvious being:
-VirusTotal's antivirus engines are commandline versions, so depending on the product, they will not behave exactly the same as the desktop versions: for instance, desktop solutions may use techniques based on behavioural analysis and count with personal firewalls that may decrease entry points and mitigate propagation, etc.
-In VirusTotal desktop-oriented solutions coexist with perimeter-oriented solutions; heuristics in this latter group may be more aggressive and paranoid, since the impact of false positives is less visible in the perimeter. It is simply not fair to compare both groups.
-Some of the solutions included in VirusTotal are parametrized (in coherence with the developer company's desire) with a different heuristic/agressiveness level than the official end-user default configuration.
thanks,
This is interesting for signature based AVs. More interestingly bypassing dynamic AV engines that execute code in a sandbox seems to be fairly trivial as well. For example allocating 100mb or memory, running a few million iterations in a loop during startup will cause most av engines to stop executing the code due to resource constraints. This paper is a really interesting read on the topic[0] 0: http://www.sevagas.c…
I guess you could only fix this with a whitelist instead of a blacklist approach.