@Rasheed My point was clear? Good. You seem to act otherwise though. This is not about me. I replied that because you took the authority to speak for the majority - "most people"- and I wanted to make it clear cut to YOU that I don't give a damn about what YOU think most people care about. At the very least, I speak for myself. For someone who does not care, your behavior is contradictory. You don't care? I get it. You don't have to repeat like a broken record. You don't care? You can put me on your ignore list.
Final Warning. Shall the Personal Banter Continue, This Thread Will Be Closed! Let's Focus Only on Chrome Sandboxed, and Not Each Other. Thank You!
Quick questions: When you say yes-on what exactly do you mean: Sandboxie or Chrome (The question was "Do you think it's easier to bypass SBIE than to bypass Chrome? This is a serious question." GJ, you answered "yes".)? Also, when you say "custom application sandboxes can restrict things more and are generally harder to break"-on what exactly do you mean: Chrome and its built-in sandbox or Sandboxie? I have to find the definition of application sandbox, to me this is pretty much all the same. What security studies and tests have been made about both Chrome and Sandboxie and by who, wha were results, could give us links to these studies and tests?
Thanks, I understand know, what exactly is Chrome' sandbox-web-browser sandbox, since it's obviously not appliation sandbox And to copy one question I have forgot to ask earlier:What security studies and tests have been made about both Chrome and Sandboxie and by who, wha were results, could give us links to these studies and tests? Big thanks in advance. No more Wilder security forums, I have to eat something before I get back.
Now back on topic, let's say that a company wants to protect all of their endpoints, and they are also running Chrome. Would you guys advice them to protect Chrome with a tool like Invincea Endpoint, or just say to them, it's better to rely on Chrome's sandbox? http://www.invincea.com/products/invincea-endpoint/
@Rasheed187 That's actually a quite complicated question. And I'm not a network security consultant, so I am not qualified to answer it. I don't know anything about Invincea's enterprise level stuff, or how it compares to current SBIE. Is the "virtualization" they talk about actual legit hardware virtualization (as with Qubes, or purportedly Bromium), or is it just copy-on-write policy sandboxing? If the former, how much code is interacting with the host OS, and on what CPU privilege level? If the the latter, what if any system calls can it block, and will it break the Chrome sandbox? You need to know that stuff to make a reasoned decision. And actual answers from actual network security consultants might vary though, depending on the consultant, the company's situation, the threats they're facing, the available hardware and choices of software, the network layout, etc. One size does not fit all.
Thanks, that does make sense. But I do think that a lot of people won't take you seriously if you advice them to rely only on Chrome's sandbox, no matter how secure it is. And I'm sure that Invincea is skilled enough to keep their tools compatible with Chrome and other browsers who might add their own sandboxing component in the future. http://www.invincea.com/use-cases/web-browsers/
@Rasheed187 Under no circumstances am I advising people to "rely only on Chrome's sandbox." Defense in depth, right? The problem is that, on Windows, all the local defensive layers share the same common weak point. Anything that uses kernel features or third-party drivers, or runs in userspace on top of the kernel, can be bypassed by the same type of vulnerability. Therefore, to a sufficiently skilled and well prepared attacker, there is no "defense in depth" because there is no depth. I certainly would not advise anyone to skimp on Windows security because of this, more just to be aware that security on Windows has become quite a limited thing. As for offices using Windows etc... Beats me. The IT world has some very serious problems right now.
I only have to say that I disagree with you and several other that Chrome's sandbox is tougher and more secure than Sandboxie, my opinions here is simple, Sully's example is one, and now there is Adobe flash player plugin vulnerability that has not been patched yet, Chrome does not protect this, Sandboxie does, and I don't buy that attack surface-like I answered before-why have anything on the computer if it increases attack surface-why are we on the net at all, than?
That doesn't mean anything, that would mean that all security options and applications that I have on my computer, it would mean that my computer is extremely vulnerable because of the generic thing and vastly increased attack surface-than why do I bother surf the net at all And what do you mean SBIE's supervisor has higher privileges? I'm sorry, but you are forgetting the fact that Sandboxie is also running on Untrusted level, as well as all applications inside Sandboxie.
I think this point of view is way too skeptical. It depends on the way you look at it, in theory it's true, but how the heck can you expect a bug free OS, without any vulnerabilities? That will never be possible. Or do you think that there's something wrong with the current Windows OS architecture? I have been running a not fully patched Win XP system for almost 10 years, protected only with sandboxing and HIPS + common sense. You already guessed it, I never got infected. That can't be simply a matter of luck. And Win 8 and 10 are much more secure than XP, so there's no reason to be so pessimistic, if you ask me.
Chrome's sandbox is not tougher at all, SBIE is using the same sandboxing methods, which it can enforce on any app. The main concern for certain people is that in theory it might be easier to bypass SBIE. To me it's a non issue. It would be interesting to see what would be harder, breaking out of Chrome's sandbox, or breaking out of Firefox protected by Sandboxie. But then again, if hackers use a so called OS kernel bug, both will fail at the same time.
Not possible, but some historic OSes have been much more secure than Windows. See for instance VMS, which Windows owes some of its concepts to. There were whole huge classes of vulnerabilities that were impossible on VMS, in both kernel and userspace. Many of those holes can still occur in e.g. Linux kernel space right now. Yes - it does all kinds of stuff in the kernel, when kernel privileges should never ever be used. Gratuitous violation of the principle of least privilege, all over the place. Kind of like with X11 on Linux, except that X11 only does very very basic graphics stuff, whereas Windows implements complex things like font rendering and scrollbars... in kernel space. You're lucky, and relatively skilled. A lot of people are neither.
@Rasheed187 Also I'd point out that there are relatively fast, compiled languages that are immune to common C/C++ issues such as buffer overflows. Ada95 is one of the less esoteric of those; also functional languages like Ocaml, Standard ML, Haskell... though functional stuff tends to be difficult for ordinary humans to learn. (To my eyes, it might as well be Greek.) There's also managed code OS designs in Java and C#, and microkernel OSes that could run current apps while presenting miniscule attack surface (e.g. Minix 3). The route taken by VMS was again different. It was written in VAX assembly, and then largely rewritten in C, but internally the kernel represents things differently than on Linux. The API is utterly different; the UNIX compatibility layer is IIRC a bunch of library calls on top of the real kernel API. Descriptors, objects that contain metadata about themselves, are used everywhere so that stuff is automatically double-checked. Point is, it's possible to write secure OSes even in unsafe languages like C. It's not easy (obviously), but it can be done. And Microsoft should definitely have enough money and resources to get it done.
If Microsoft did that, their planned obsolescence business model would suffer. If they made a secure OS, they couldn't use all of the scare tactics to coerce people to update. They don't want users to have secure operating systems any more than the NSA does.
Rasheed you are running, XP still? Than you are my man, I have finally found someone on XP could in pm send me what security applications do you use, I need advice-despite that I have also never been infected-unless I wanted to test something on purpose, but the main defense were always AppGuard, tightly configured Sandboxie and HMPA and Hitman Pro and Malwarebytes Anti-Malware free.
Exactly, this is all true about Sandboxie and its toughness, plus curt from Invincea confirmed me on their forum is that everything that runs inside Sandboxie every single application, process, exe, dll and everything else starts/runs on Untrusted integrity level-the same Chrome's sandbox and web-browserl!!!! The one time I was almost infected was again with unsandboxed Chrome basically doing the same thing as Sully did, but my friend stopped me, and said not to open it and not to click it, because he has done the same thing and was infected, however just recently the reason why I was infected-was basically my own security/protection test to see if Chrome's sandbox is going to protect me-it didn't, plain and simple, I did that same against sandboxed Chrome (with Sandboxie on top of Chrome), and nothing was ever infected by anything at all, jeez I even played with this infection inside Sandboxie that gave me all forms of messages, until I decided to delete it once and for all with one click inside Sandboxie. Chrome is good at protection while you surf the net but it will not protect you against situations like this, because it is only a web-browser and nothing else click something wrong and you are infected-end of story, but Sandboxie on top of Chrome is simply more secure and you will never get infected by anything at all. However, I have decided to drop Chrome, because of the reasons others mention, I use Firefox and Opera and Internet Explorer now under Sandboxie's supervision.
@Gullible Jones Well, I wouldn't quite say 'back'. Mostly I get to work really early and my caffeine doesn't kick in for a good 30 minutes. Chrome does some interesting things here. I am not sure if this is a stable feature yet but it drops kernel32.dll in the renderer, preventing the renderer from accessing underlying win32 functions, limiting attack surface. I think this is really interesting in the context of whether Sandboxie is more trouble than it's worth. Google is taking serious measures here to ensure that as little exists in the renderer address space as possible, do you really want to be injecting code into there? @Windows_Security Until recently (and possibly this is still the case?) kernel vulnerabilities were not eligible for reward in pwn2own, only 'pure-browser' vulnerabilities. I believe this was removed as a restriction (in response to browser vendors realizing they can't ignore this huge issue), and Chrome was popped that same year with a system call made from within the sandbox. The Linux bypasses have also been kernel vulns like futex.
I am not sure about the status but I think with Chrome 43 the --enable-win32k-renderer-lockdown is enabled by default
@Hungry Man - Linux bypasses on the setuid/seccomp sandbox? Wow. That's news to me. Anyway, cool that Chrome on Windows is doing something to avoid the kernel attack circus.
Yes, I remember there was such a vulnerability. I think it was this one. I don't know, though, how exactly exploiting this vulnerability was achieved. Perhaps you have a better understanding. EDIT: Another one with medium score.
OK, now I understand where you're coming from, but this is something that M$ can't change, they would have to rewrite the whole OS. I think Microsoft is at least doing everything what they can to beef up security, and have already made it harder to exploit the OS kernel. http://www.pcmag.com/article2/0,2817,2408016,00.asp Actually, I have a feeling that most of us Wilders Security guys don't get infected. For the most part it isn't luck, what I'm seeing is that people and businesses get infected in the real world by the same methods that were used 10 years ago. Hackers are not using rocket science or magic to infect people. Current security tools are quite effective if you know how to use them.
IMO virtualization is a killer feature, I already gave an example how it might be able to protect against ransomware that breaks out of the sandbox. If I'm correct, virtualization is done by a driver, so hackers will also need to bypass that, to escape isolation. I would pick application sandboxing (isolation + virtualization) anytime over a browser's own sandbox. No, I have switched to Win 8 in December 2014, because I bought a new PC.
Not really - they'd have to rewrite their kernel, and maintain a legacy compatibility layer for Win32 apps. Kind of like Wine on Linux. Relegate the former kernel stuff to userspace libraries. This would not be terribly bad for performance - Wine for instance is all userspace, and performs pretty well, even on Linux with its rubbish graphics drivers. And FYI, they have at least considered such an approach - some of their experimental OSes, prototypes for hypothetical Windows versions, were microkernels or even managed code. Just skill, then. Point is, a lot of people don't have the time/expertise/aptitude to use a HIPS or such. If hardware virtualization, maybe yes. Otherwise probably not. A driver runs in the same privilege ring as the kernel.You might be able to achieve better isolation with a driver than native Windows mechanisms, but I doubt that SBIE does, because (again) it has to be more widely compatible.
