info on Chromium browser needed

While I agree, I think in practice that might be harder to avoid. Plenty of legitimate sites get hijacked.. and sometimes a misclick on an ad while surfing a legit site can lead to malware. It happens.

The whole point, IMO, is to maximize security. If you run your browser for two weeks without the latest update, you are probably missing out on a fix for some patched flaw. I know most people in here are professionals, and some can manage themselves... but I've seen this mistake made many times. I've trusted users and staff to manage things like their own Windows and software updates... some times they were inconvenienced by automatic updating. It almost never works out. Almost everyone puts it off. Some of them do this for MONTHS.

Now, I'm not trying to tell anyone what to do. To each his own. I'm merely arguing that there is a decent security benefit to automatic updates.. and IMO there really aren't too many reasons NOT to use them. Letting the computers do it helps avoid some of the faults that come from relying on user interaction..

 

If you missed out some security patches from your browser (ie. bug that allow drive-by)
you probably won't notice that you actually may have layers of security to mitigate the problems such as the ff:


you may have dns that may block malicious links from drive-by
you may have download directory trick to block execution or lowered rights of downloaded files.
you may have system virtualization
you may have sandboxed the browser
you may have linkscanners installed
your browser (chromium) has malware protection which is ON by default and is auto-updated every 30mins.

you may have UAC
you may be running on Standard User Account
you may have installed HIPS
you may have antivirus installed on PC.

 

I can see why you might view it like this, but maybe you aren't following it through far enough?

We know that when the OS is installed, every directory and some files are set with specific rights, both DACL and SACL. We know that the DACL states what rights are allowed, what groups and users rights are, etc. We know that SACL is typically used in the past for auditing, but now also includes the Integrity Level.

We know that every object gets an IL. We know that hardly any objects or directories have an explicitly state IL from install. We know that when an object is created/accessed, if there is no explicit IL, then either a Medium or High IL is assigned, depending upon whether it is a user or admin account being used.

We can clearly see that by manipulating Integrity Levels, we can purposefully lower them to a level that is under that of the common user - or Medium IL. We know that by default a Low IL cannot "execute up" or "write up" files or objects at higher levels, but that a Low IL is allowed to "read up" - meaning it can read but not modify or execute. This is not much different than being able to open or read a file in %programfiles% when you are a user. But unlike DACLs, Integrity Levels make it very secure due to the fact that a lower IL absolutely cannot execute a higher IL. It would take a deny execute DACL to do that, and it would have to be explicitly set and would have to be propagated to all children and grand-children etc, whereas the IL is already in place.

When you describe the matter of setting an IL to Low on many directories, and that it might defeat the purpose, how far out have you ran with this thought? If you were to set Firefox to Low IL, you would need to also set the profile and temp directories as well. This makes sense then that the %programfiles%\mozilla firefox\ directory is still at a Med/High IL, and that only Firefox.exe is at Low IL. Thus far, only one executable is at Low IL and it has nowhere to modify.

As you set the profile and temp directories at Low IL, now Firefox can actually modify those very things it is meant to modify. This is niether good nor bad, because it is meant to do so, and in fact, even in a user account it has those rights. The inclusion of these directories at Low IL is not creating a "hole" but rather allowing what is permissible.

If we then look at Adobe, and we realize that to use it we need to set it to Low IL as well, we must contemplate what could go "wrong" by doing so. A Med/High IL could obviously modify the Adobe data at a Low IL, but that is acceptible, so while you can worry about it, it does no good really. But we suppose that for some reason setting the Adobe data to Low IL makes it unsafe.. but how? If Adobe is that prone to issues, then perhaps it is not the application that should be used. If the Low IL browser process contracts a malware that is designed to compromise the Adobe data, and because both it and the browser are at Low IL, it is allowed to do so, where does it go? If you later start Adobe from a Med/High IL process, Adobe should start at Low IL becuase you have explicitly told it to do so. If it does indeed start at a Low IL, what exactly is it going to do?

Of course, these assumptions are based upon the fact that using a Low Integrity Level is applied "in bulk" rather than to specifically target smaller areas, such as a .dll or a .exe. If we step back and look at it, we can come to any conclusion we like if we look hard enough. But what about in common practice? You are correct when you say that most won't use it. They will not. While we more learned users don't find it difficult at all, it is most certainly difficult for many. But I would also say that those same users who choose to use Integrity Levels to their advantage are also using other programs to thier advantage. One example would be rather than to use the very bloated and over-priced Adobe software, they might (according to a poll anyway) use Foxit pdf reader. They can then apply the Low IL to one executable.

I am not saying you are incorrect or that what you say will never happen, because there is a degree of truth there. But I do think the way you described it takes it quite a bit out of context as to how most of us here who use it actually use it. So, in keeping things in a right frame, I cannot see the way we (I) use it producing the fruits of your concern.

Of course, all that being said, I could well be wrong. I thought about your statement for a good bit, did a little extra reading on the topic, and if used logically, I just don't see it being a worry at all.

Sul.

 

Once I did want to try chromium yet was unable to find the d/l link for it

strange as it may seem I need you to verify this for me, please

is this the source of the browser:
http://build.chromium.org/f/chromium/snapshots/

where is the latest stable version to be found?

 

I don't know why so many Open Source programs are so cryptic, maybe to make them less attractive to the general public? beats me...

 

Can't a lot of the browser drive by problems also be mitigated or fixed by updating java, flash, adobe reader, etc?

 

Well, what I'm referring to is in contrast to how chrome currently performs it. This approach has some potential flaws as well... but we start with a process that has a medium IL. It spawns process with low IL. These spawned processes cannot modify any of your user settings (application data / local settings / AppData, etc). It can't really do anything.

However, if you go changing the IL of even a single executable in the chrome folder, or in the Adobe folder... and if you change the application data folders to low IL and your temp folder to low IL... then these low IL processes can potentially modify all of these locations (assuming they have proper NTFS permissions, or manage to elevate to do so).

Let's assume you do this on 10-12 of your most common applications.

IMO, now you are in a much worse off position than before when an application like chrome launches a low IL process. Now, all of your user profile folders are easily writable. This is no longer truly "sandboxed", since the low IL process isn't really write restricted any more than it was without low IL. It has all these writable areas. Our original example (with the default chrome setup) could NOT write to these areas - unless the main chrome executable was compromised... but now the app doesn't even need to compromise anything. You've given it access to all these other user writable areas by default. Malicious code in adobe reader can now change your chrome profile and maybe add an extension that steals your passwords..

Now, if we move on to the program folders, as a standard user you'd need elevation of privilege to overwrite something like acrord32.exe .. but before (chrome default) you'd need privilege escalation and a bypass of low IL restriction. You've taken that adobe reader executable and you've made it writable by a low IL process.

Again, if you do this for one app... and only one app, none of this really matters. If its the only application that ever runs in low IL, you are no worse off. Its the scaling that creates an issue..

 

That is a nice description of your take on it. I think in context what you describe has some merit. I am not sure on how that effects what I have been doing. Interesting stuff, I will have to think about that for a bit. Thanks for not taking it personal and staying on the topic!

Sul.

 

No worries mate, I'm just discussing it for discussion sake ... Thanks to you as well for the well thought out responses..

 

As always, this is all about risk ponderation. If people start applying a low integrity level to everything (It would be a daunting task, by the way!), then any low integrity level object could read, write and execute to any of those areas, unless we remove permissions, in whatever areas we'd like to.

This would KILL the very same purpose we're after - SECURE the rest of the system from the web browser. I mean, why would we force the web browser to run with a low integrity level, and then let it write and execute to other areas as well, that otherwise would not be writeable and executable by those low objects, right? And, when I mean web browser (At least, in my own approach!), I mean the web browser I use for general browsing purposes.

Actually, I use Chromium for all purposes, but different "installs" and profiles.

This is where icacls starts to fail. It only allows you to change things to a certain level.

For example, I can have my general purpose browser profile set to a low integrity level, and one other for more serious stuff with a higher integrity level and make it impossible for low integrity level objects to read, execute and write to that higher integrity level object.

icacls does not allow that.

Also, when you need to set the Temp folder to a low integrity level, to allow the web browser (you) to download files, you don't need to propagate the low IL to all objects within the Temp folder. icacls allows you not to propagate inheritance.

So, what does this mean? The web browser's low integrity level would only be allowed to write to Temp folder only, but not to any of its sub-folders. This creates isolation as well.

Anyway... I hope you're seeing where I'm trying to get with this. You can't blindly apply integrity levels like crazy, and then expect to still be secure.

But, I still fail to see why something with a low integrity level, placed outside Program Files would mess with objects in Program Files dir.

I also fail to understand why would anyone apply a low integrity level to AppData folder itself? AFAIK, there is no such need.

So, if I apply a low integrity level to AppData\Local\Temp, then these low integrity level objects (Temp folder) won't be able to write and execute to AppData\Local. If I set a low integrity level to Temp folder without inheritance propagation, then the low integrity level objects won't be able to write and execute to the rest of Temp folder either. Unless I'm wrong.

Again, I'm saying this from the perspective you won't go changing ILs like crazy.

Do it only for what is really needed... like the general web browser profile, and that's pretty much it.

-edit-

Everything we're discussing is all about assumptions. Assumptions in different scenarios, and they all would become valid in those different scenarios. So, I'm not trying to show my view as the only valid one. Far from it. I'm actually glad this was brought up to discussion.

One more example, just to show that assuming a different scenarios, things could go nastier.

As I mentioned, I run my Chromium general browser "install" with a low IL. I got no concerns. It can't run write and execute to higher integrity level areas. But, now imagine that I run this browser inside Sandboxie. Sandboxie will allow interaction with medium IL areas, that otherwise would be out of reach to the web browser. Imagine there's a security flaw in Sandboxie, which allows an infection to occur to medium IL areas, that otherwise would never have happened if I didn't run the web browser inside Sandboxie.

It's just a possible scenario, showing that's it's all about risk ponderation.

 

i don't think Chromium can be said to have a stable version at all.

they're all 'experimental' versions, from what i gather.
--------------------------------
btw, tnx for the input folks.
it's an interesting topic to follow.

 

Outside of social engineering tricks all of those things can be dealt with by the browser -- including drive by downloads.

 

And this is why I don't run low IL except for Chrome and IE9s defaults. Lowering your IL in a bunch of folders is a security issue after a very short point.

 

Oh man, I love topics like this. So many different viewpoints tossed around someone is sure to walk away with better knowledge

Regarding Sandboxie, I am not sure I follow you. In a recent test I was looking to see what ILs would do in the sandbox. It appears that similar to ACLs, ILs within the sandbox are not seen as "normal". This is likely due to the fact that SbieCtrl.exe is running at High IL, so when you start an application explicitly set to Low IL, SbieCtrl.exe does not care what the OS said because it is virtualizing it, and unless you use "drop rights", it starts the process "within" the sandbox at the same IL that SbieCtrl.exe uses - high in my case.

But with Chromium it is different, sort of. In a similar manner, SbieCtrl.exe allows Chromium to start High even though I tell it to start Low using icacl. But, once each process is started (extensions or tabs), they are all at Low IL within the sandbox. If I start them outside of the sandbox, then all is at Low IL just as icacl was instructed to do.

Now, when you mention SBIE will allow this med or high process (Chromium main process) to interact with otherwise out of reach areas, it is an implication that is two sided. On one side, yes, it can read from objects that are at med/high IL. But on the other side, it is sandboxed still, but do not forget that (IMO) when SBIE is circumvented, the real underlying DACL/SACL kicks in. In tests at least with SRP "basic user" or DropMyRights, once a hole is created in the sandbox a restricted process has no access to the real OS because its restrictions are realized by the OS, even though within the sandbox, if not using "drop rights" the process can access the virtualized areas without issue. I have not tried to see if my Low IL Chromium started in SBIE can actually write/modify to a Med/High IL if a hole is created in the sandbox, but I assume it behaves the same way.

Now that is not to say that there could not be a method a hacker uses when exploiting SBIE that won't allow it, but from a generic viewpoint, if the sandbox fails to keep things separated, when something does escape the OS picks up what the real rights and restrictions are and applies them.

Nice discussion here for sure.

Sul.

 

Actually it isn't a security issue for the system, only for your browser/profile.

If you don't want to keep your profile completely dynamic but are fine with configuring it and leaving it in a static state, there is no reason to apply a Low IL to it. Most of the browsers will run fine with very little actually needing a Low IL in addition, but most who use Low ILs want to have it run like normal, so they apply Low IL to the profile.

In addition to this, if you don't apply Low IL to (depending) the temp or downloads directory, you have additional security because the browser can no longer download. Of course you could also set Low IL on the downloads folder and decide if you wanted the directory only to have the Low IL, or to propagate it to the objects placed within it, or as m00nbl00d indicated you can decide that subdirectories would be at normal Med/High and only objects would get Low IL. So many variations.

Take it a step further an apply some DACL restrictions, and see even more robust security.

Of course this all hinges upon the fact that one does not just blindly apply this or that wherever they please. But then, thats why it isn't discussed much except for geeky places like this, isn't it?

Sul.

 

Just something I wanted to add, which I previously forgot.

You always need to look at it from more than just one perspective. You're looking at it, from the perspective of a low integrity level. But, do not forget that you can't just look from that perspective.

To make things simpler, regarding ILs, I'll be mentioned low and medium integrity levels, either within a standard user account or administrator account with UAC enabled.

Taking, again, the web browser as an example. OK. I run Chromium with a low integrity level. It can only write and modify low integrity level areas, and that pretty much is its own profile folder.

How exactly will something here manage to write to Program Files? You need to be an administrator or have administrator rights to write to Program Files. Never a low integrity level will manage to do it, unless there's a bug in the way Windows manages ILs.

So, if a low IL object has no such permissions, and unless there's some inherent problem with the way Windows manages ILs... How will it happen?

Now, let's take a media player scenario. I'm running normally. It has no sandbox, no explicit low integrity level. This media player can read/write/execute to other low and medium areas. A security bug could even allow it to access high level areas.

If I apply an explicit medium integrity level, then it still can read/write/execute to low and medium level areas. But, it won't be able to access high level areas.

Question: What would be worse? For this media player to be able read/write/execute to both low and medium level areas, or be restrict to a low level area only?

My answer is: I'm applying a low integrity level to my web browser, but I only use it for general purposes. I got no issues with the media player being able to read/write/execute to its profile, or read from the browser's process. Heck, with a medium level inherited from my standard account could still do it, anyway.

So, used wisely...

Nothing is foolproof, and that's the reason you CANNOT apply the same integrity level to everything!!!! This kills the isolation purpose, in the first place.

 

Yes, that's what I had in mind. Without such scenario any object that you can save to Medium/High level areas, using Sandboxie as a "middle man", will still inherit the low integrity level.

What I mentioned was just based on an assumption, and should be seen as such, and nothing else.

Kudos to Sandboxie, actually. I can open PDFs from within the web browser, without having to mess with the PDF reader levels, even without sandboxing the browser.

 

I find threads like this help to temper my viewpoint because I likely am abnormal from "average". I have actually pretty minimal Low IL settings, and use SBIE so much that I have never felt the need to mess with certain things. Further, I don't use the same applications the majority likely due, such as Adobe. I like the lesser known and "lighter" tools, like older Foxit reader.

Many times I have to place myself in others shoes to see why they say what they do. I already know what is happening on my machine and why I configured it as such. I must then examine what others say and try to decide if the way I do things applies in the same manner as how others see/do.

Sul.

 

I think we are all pretty much on the same page... I would not go around enabling other apps to run at low IL. Leaving it at the browser would be the best idea.

As far as the program files thing, if you change the chrome.exe (or whatever.exe) to low IL, then all it would take is a UAC elevation to overwrite it (assuming standard user / UAC setups). Honestly, I think it would be far safer if the .exe's themselves (and the folders that host them) stayed medium IL.

What would work better is what chrome does, and sort of provides a launcher for the real chrome processes. This would allow all of your actual files to be unwritable by low IL processes, even with proper NTFS permissions...

 

I stand corrected. You are correct that UAC does indeed ignore the explicit SACL on the object and does indeed start it with High IL rather than what it was set to.

It appears to me then that Integrity Levels are not as robust within the confines of UAC as they are when you run as Admin. What happens in admin is that since you use the one security token all the time rather than the two you have with UAC, is that if you set an explicit SACL, it always applies and always starts at the IL you set it to.

Sul.

 

I knew something good was going to come of this type of discussion.. well, sort of.

It appears that ILs are not quite operating in the way I had thought. From an admin account, they react and behave as I would expect.. I set it to Low, it always starts as Low.

However, there is a flag

Depending on this flag, a process with a mandatory Low IL will either start at the lowest level found, or at the level of the parent process. So if the parent process is at Med/High, a Low IL object will start at Med/High. UAC appears to allow the child process to start at a higher IL.

Always something new and exciting to discover..

Sul.

 

Yes, but there wouldn't be a direct way to elevate a low IL object. A malicious process would have to already be executing with administrator privileges. And, what would then be the purpose of hijacking the Low IL object?

Within the context of a standard user account, if you right-click a Low IL object, it will fail to elevate. The only way for you to execute the Low IL object is to make use of an already elevated object to execute the Low IL and raise its integrity level.

So, unless this Low IL manages to become a High IL, how will it get to Program Files?

 

Cgeek,

I appreciate it mate!

Was also wondering what is the difference between:chrome-win32.zip / mini_installer.exe.

edit//ok, get it, .zip is simply portable one while .exe is the installing one

how do you guys work with portable browsers? leave it on partition D ? or rather put it on C:


how to work with it while using ShadowDefender?


have a good one

 

I create a directory c:\program files\chromium and place the files there. I do this because Program Files has certain rights/restrictions in place, and I don't want the application messed with. The profile lives in AppData and is created there for you. So all you have to do is copy/paste the contents of the .zip file there, overwriting the prior version.

You can put it anywhere you like. I suppose though that to maintain integrity you want to put it someplace an Admin has rights to an users can only read/execute.

If you want it truly portable, there might be something at portable apps that would work better than just pasting it to a flash drive or similar.

Sul.

 

Sounds logical, high 5 for Sully!

back to Chromium now... 14th of June marks my 1st day on it.