Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Oh oh - seems my Gentoo's been ransomwared!! Oh No!
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5  Next  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
eohrnberger
Apprentice
Apprentice


Joined: 09 Dec 2004
Posts: 240

PostPosted: Tue Mar 21, 2017 3:28 pm    Post subject: Reply with quote

1clue wrote:
eccerr0r wrote:
Ant P. wrote:
eccerr0r wrote:
We need less complex software that can be proven correct... perhaps software writer responsibility up to the cost of the purchase price?

That's already the case here. Count how many things you have installed where the license includes a long all-caps disclaimer "no warranty, not even implied warranty that this will actually do what it says" - and see if you can find a single one that doesn't.

As long as we didn't pay for it, it is our responsibility if it breaks. So all GNU software we get to keep the pieces if it breaks. I suppose the comment was not a solution but rather hoping that we have a chance to detect/fix it ourselves, but the complexity is a big problem, and hoping that for-pay software will indemnify our problem (FAT CHANCE! or do we need more laws...)

---

Backups are costly as well if we have to go back many, many revisions. I'm hoping that there won't later be "dormant" or "logic bomb" software that looks innocuous at first, and gets backed up for many revisions. Once again, complexity is the killer.


Are you guys actually going there? Even for-pay software does absolutely nothing to protect the computer from the idiots at the keyboard. The OP ran a web browser as root and went out to the unprotected Internet. That's the same thing as putting your car through the crusher and then expecting the original manufacturer's warranty to cover it. If people start suing the programmers for idiotic shit done by the users then programmers will stop writing software. Or they'll charge enough to protect them from people who do stupid shit.

This is, by the way, exactly the reason health care costs so much in the USA. Having been to other countries where a full-spine MRI costs USD $5 without insurance and you can get half a dozen cavities filled along with a crown and a root canal for USD $250 -- again without insurance -- I can assert that litigation against others for one's own mistakes can have no good long-term outcome.


I'd have to agree. As the OP, I did something stupid, something I should have known not to do, and did it anyway. It's on me, and I wouldn't want to have it any other way.

That being said, I've changed root passwords, banned a few more IPs, setup what I needed under a non-privileged user account, and haven't seen anything weird going on. I may be through this, but time will tell.
Cautiously optimistic at this point.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Tue Mar 21, 2017 3:31 pm    Post subject: Reply with quote

eohrnberger,

So the root kits are still installed?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Tue Mar 21, 2017 4:20 pm    Post subject: Reply with quote

eccerr0r wrote:
However we still don't know for sure what the entry mechanism is. We know running stuff as root because we know that there may be bugs in it. This is not like driving a car in a crusher, this is like driving a car off road because the car should have been fine off road, but history as told that the manufacturer sometimes puts questionable springs and shocks on it. Without scrutinizing the car, we won't know. People who know that it's very likely that off road suspension was not installed but have no way of checking (and neither can the manufacturer), so we just drive the car on paved roads so we never lose suspension and crash because of steering failure. These are the people who don't run as root.


Bad analogy. The core of Linux is solid. Running as root is the same as deliberately turning off all security and all sanity checks. Running a browser as root means you give not only the website you logged into full authority to run any script, but also any third-party website ad that might get loaded, and any tertiary sites that might be loaded from there. You've already clicked OK and you want everything that tries to run to be successful. Because you're root.

Quote:

Running code on the native machine from within a VM is completely improper behavior... Running as root should have not been an issue, after all, VMWare needs to be run as root and you'd certainly be up in arms if running a code sequence inside the VM and suddenly your host is infected with encryption ransomware. It's not like the OP gave permission to run code that encrypts his computer. The buggy code allowed something that should have never been allowed.


VMs run as constrained users all the time. Running authorized code on the bare metal from a VM is completely proper. That's what the virtualization software does when it emulates a CDROM or some other piece of "hardware" you don't actually have.

Quote:

I am tired of people charging money for crap software that have bugs, never mind the security bugs. It's always time to market, time to market. And people think buggy software is somehow "acceptable". No. This is bad practice and it needs to stop despite the bean counters. Can't say it's 100% their fault, it's one of these things where someone jumped, it wasn't so bad, now everyone else now needs to follow suit or be left behind.

---

Where did those other countries get the MRI machine? They could not have recuperated the cost of the machine at $5 per scan unless there perhaps was a government subsidy somewhere that you don't see. In the US someone made an investment, are only owned by a few for-profit companies, they can charge however much they want. Not an insurance issue, pure greed.

In any case, the USA is clearly a litigious society... unfortunately the underlying reason behind it is because everyone wants to be equal to everyone else. I'll leave it at that.


The economy in Colombia is almost completely capitalism. There is no sales tax, there is a small property tax but that's it as far as I can see. Cars pay for license plates and gas is extremely expensive. The average employed worker I saw there made about $10 USD per 12 hour work day. Chances are they feed their family and probably their parents or grandparents with that. There is no government subsidy because the government collects almost nothing from the population. You can buy insurance for the big stuff like heart surgery but most people don't have it and get along fine without it.

Edit: There is also no unemployment insurance, no medicare, no safety net. If you don't have a job and you don't have caring family who has a job, then you're on the streets. Unemployment is extremely high there. If you don't want to work then there are lots of people who do.

The MRI machine was about 10 years old, based on the opinion of a neurosurgeon who looked at the scan files in the USA when we got back. It was probably bought used. That said, it wasn't at a hospital. Most of that sort of expensive hardware gets its own building and its own staff, and the doctors tell you to go get an MRI. You get on the bus, travel from your home town to one of the cities which have that sort of machine and you sit in line and wait for your turn. The machine is constantly in use. While one patient is being scanned the next one is dressing in the gown and removing jewelry. The one after that is getting the gown and the instructions from the staff. They rely on continuous use to pay for the machines that cost a lot of money, because if they charged what a single MRI costs in the USA then nobody would get an MRI. They found a way to minimize costs (either buy old equipment or buy new and keep it longer, and continuous utilization) and they went with it.


Last edited by 1clue on Tue Mar 21, 2017 5:34 pm; edited 1 time in total
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Tue Mar 21, 2017 4:29 pm    Post subject: Reply with quote

eohrnberger wrote:
I'd have to agree. As the OP, I did something stupid, something I should have known not to do, and did it anyway. It's on me, and I wouldn't want to have it any other way.

That being said, I've changed root passwords, banned a few more IPs, setup what I needed under a non-privileged user account, and haven't seen anything weird going on. I may be through this, but time will tell.
Cautiously optimistic at this point.


Please keep in mind that I'm not trying to abuse you here. I believe you understand what happened and why. eccerr0r seems to think bugs are involved, and although it's possible I think it's not very likely.

Personally of all the times I've been hacked or had malware I have never been comfortable with the box after that. The nature of my work is such that if even a minor box gets hacked then that poses a serious risk to every other box in my control, and I can't tolerate that. For me, your situation requires scraping off the entire system and starting over. There's no other way to be absolutely sure that you got everything off.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Tue Mar 21, 2017 8:20 pm    Post subject: Reply with quote

Indeed the crusher analogy was indeed a bad analogy. It is for a fact that these complicated pieces of software we do not know of every aspect of them and somewhere there could be a bug that can be exploited to run code that was not expected.

User accounts are only a safety net that should not have been necessary if the VM was doing its job - whether it's firefox running html code, adobe-flash running flash code, or VMWare running a VM. All of these should be shielding running arbitrary native code on the host processor and only running code that were permitted by the code itself. If it's allowing arbitrary native code that's presented inside the VM to run outside the VM, this is a bug. Running as root only amplifies the problem as now you lose control of the entire system instead of the specific actions the program was supposed to be able to control.

What is this "authorized code?" Code is code... Of course you have to give it code to run whether it's HTML or flash or a VM image, it's supposed to run that well defined code. But it's not supposed to bypass the protections given by the VM and run arbitrary code directly on the host.

There are clearly bugs involved. If there are no bugs involved then we should see user accounts being taken over left and right, regular user accounts on Linux boxes are VERY useful to hackers for DDoS, mail spam, fake user hits, and more ssh hacking - all of which do not need root. It is absolutely not normal for a web page or flash program to be able to write to your ~/.profile and make it automatically start sending spam or running ssh bruteforce attacks to other machines every time you log in, whether you run the browser or not.

If you wish to prove wrong, be my guest - start writing flash and html that will either encrypt my home directory or upload everything to another server without my knowledge by merely clicking on a website. Or write a code sequence that runs VM that will also encrypt my home directory on my VM's hypervisor host. Then we can submit how you did them to Adobe or QEMU as bug exploits that need to be fixed.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Tue Mar 21, 2017 10:24 pm    Post subject: Reply with quote

eccerr0r wrote:
Indeed the crusher analogy was indeed a bad analogy.


With respect to the expectation of financial compensation from programmers of free software for bugs found in the code, it was perfect. Root account exists explicitly for the purpose of limited system administration where privileges are escalated.

Quote:

It is for a fact that these complicated pieces of software we do not know of every aspect of them and somewhere there could be a bug that can be exploited to run code that was not expected.


You have just described all of software, everywhere. There are reliable mathematical formula which describe the number of bugs based on code complexity and maturity.

Quote:

User accounts are only a safety net that should not have been necessary if the VM was doing its job - whether it's firefox running html code, adobe-flash running flash code, or VMWare running a VM. All of these should be shielding running arbitrary native code on the host processor and only running code that were permitted by the code itself. If it's allowing arbitrary native code that's presented inside the VM to run outside the VM, this is a bug. Running as root only amplifies the problem as now you lose control of the entire system instead of the specific actions the program was supposed to be able to control.


Explicitly false. EVERY Linux distro has strong warnings about running software unnecessarily as root. EVERY howto, every security wiki, every bit of documentation. It used to be that opening any browser as root user would get a warning dialog saying you're doing something very stupid. I don't know if it still does because I don't and won't open a browser as root. The entire purpose of the root account is that sometimes an administrator needs to do something special, and they are explicitly assumed to know what they are doing (because why else would you be root?) and all the security stops are pulled. Some virtualization software refuses to run as root.

https://wiki.archlinux.org/index.php/Users_and_groups

LINUX IS NOT WINDOWS! LINUX IS NOT MAC OS! You are not a consumer. You've learned about Linux and UNIX in general, you are supposed to understand certain core facts about it, and you've chosen to install Linux in place of some other operating system. Linux is an expert system for expert users. It has fairly sophisticated user security and it is configured by default to use that security.

If you run random end-user software as root, then you pretty much deserve whatever you get.

Quote:

What is this "authorized code?" Code is code... Of course you have to give it code to run whether it's HTML or flash or a VM image, it's supposed to run that well defined code. But it's not supposed to bypass the protections given by the VM and run arbitrary code directly on the host.


Operating system code is authorized code. Hypervisor code is authorized code. For example, if your system supports hardware acceleration for graphics, encryption, compression, whatever else you may choose to pass that functionality on to your VM. Authorized code SHOULD be carefully vetted by somebody. Authorized code should NOT be some random flash video from a third-party popup ad. Typically we prevent the latter by not doing something like running a web browser as root.

Look. You can try to insist that programmers protect you from your own laziness and ignorance all you want, but it will not happen. Go run ios or something. Even Windows doesn't want you running as Administrator all the time, and Mac OS doesn't even tell its users that a root account exists. Pretty much every ios or android phone warranty is void as soon as you root it, for good reason.
Quote:

There are clearly bugs involved. If there are no bugs involved then we should see user accounts being taken over left and right, regular user accounts on Linux boxes are VERY useful to hackers for DDoS, mail spam, fake user hits, and more ssh hacking - all of which do not need root. It is absolutely not normal for a web page or flash program to be able to write to your ~/.profile and make it automatically start sending spam or running ssh bruteforce attacks to other machines every time you log in, whether you run the browser or not.


If bugs were around then we would see more privilege escalations. Everyone wants a root exploit because there are explicitly, BY DESIGN, no security checks on the root account.

Quote:

If you wish to prove wrong, be my guest - start writing flash and html that will either encrypt my home directory or upload everything to another server without my knowledge by merely clicking on a website. Or write a code sequence that runs VM that will also encrypt my home directory on my VM's hypervisor host. Then we can submit how you did them to Adobe or QEMU as bug exploits that need to be fixed.


Why would I waste my time? You're the one going against UNIX best practices, you should bear the burden of proof. You're arguing whether a user should be protected from themselves when running end-user software as root. I want you to find even ONE linux distro or commercial UNIX vendor who suggests that this is not an insanely bad idea. Ask the question on any Linux forum or UNIX forum. And brace yourself.

I don't write flash code. I can certainly write normal code which encrypts my home directory, it's no big deal. I can certainly run that same script as root and get the entire disk-based file structure as long as I don't try hitting /dev or /proc or other virtual filesystems. You're trying to get me to prove something you know to be false.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Tue Mar 21, 2017 10:42 pm    Post subject: Reply with quote

@eccerr0r,

http://unix.stackexchange.com/questions/1052/concern-about-logging-in-as-root-overrated

This pretty much sums it up. I would have tried to make a few more points, but long story short you can do whatever you want on your box.

I take issue when you claim to others that they should also do something stupid, or by asserting that there should be no reason why you can't run a web browser as root, as that's a deliberate untruth regarding the nature and purpose of root user, since the concept of UNIX security came into existence.

Edit: Rather than spam the thread I'll add this link: https://en.wikipedia.org/wiki/Principle_of_least_privilege
Back to top
View user's profile Send private message
eohrnberger
Apprentice
Apprentice


Joined: 09 Dec 2004
Posts: 240

PostPosted: Tue Mar 21, 2017 11:01 pm    Post subject: Reply with quote

NeddySeagoon wrote:
eohrnberger,

So the root kits are still installed?


Don't think there are any. rkhunter and chrootkit both come up empty. If you know of another scanner, I'll run it.

I'm keeping my eye on it. Might not have installed one. I suppose that if I were to recompile everything, wouldn't that flush out any altered binaries?

I'm still learning (aren't we all always all the time?), and this is a learning experience too.
Back to top
View user's profile Send private message
eohrnberger
Apprentice
Apprentice


Joined: 09 Dec 2004
Posts: 240

PostPosted: Tue Mar 21, 2017 11:51 pm    Post subject: Reply with quote

1clue wrote:
eohrnberger wrote:
I'd have to agree. As the OP, I did something stupid, something I should have known not to do, and did it anyway. It's on me, and I wouldn't want to have it any other way.

That being said, I've changed root passwords, banned a few more IPs, setup what I needed under a non-privileged user account, and haven't seen anything weird going on. I may be through this, but time will tell.
Cautiously optimistic at this point.


Please keep in mind that I'm not trying to abuse you here. I believe you understand what happened and why. eccerr0r seems to think bugs are involved, and although it's possible I think it's not very likely.

Personally of all the times I've been hacked or had malware I have never been comfortable with the box after that. The nature of my work is such that if even a minor box gets hacked then that poses a serious risk to every other box in my control, and I can't tolerate that. For me, your situation requires scraping off the entire system and starting over. There's no other way to be absolutely sure that you got everything off.


No worries. If I feel abused, I'll let you know.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Tue Mar 21, 2017 11:58 pm    Post subject: Reply with quote

eohrnberger,

eohrnberger wrote:
I suppose that if I were to recompile everything, wouldn't that flush out any altered binaries?


Maybe. Who knows what the altered/hidden binaries are doing while you rebuild, or even now while you continue to use the install.
Perhaps you have an open mail relay that's distributing spam.
Perhaps you are part of a bot net, being used for DDos attacks.
The point is you don't know.

rkhunter and chrootkit are not perfect.

The only responsible thing to do with a compromised system is to isolate it from the network, destroy the install and reinstall it.
By all means, image the install if you want to perform some forensic examinations.

Destroying the install means making new partition tables.

Paranoid readers may want to flash their BIOSs too, to ensure there is no trojan lurking there.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
jonathan183
Guru
Guru


Joined: 13 Dec 2011
Posts: 318

PostPosted: Wed Mar 22, 2017 12:00 am    Post subject: Reply with quote

eohrnberger wrote:
I suppose that if I were to recompile everything, wouldn't that flush out any altered binaries?
No ... a fresh install is the only way you can be sure the system is clean. Ken Thompson trusting trust.

I'm still interested in how your system got compromised because the same method may be available on other systems. Doing things as root made things worse but a regular user account could still result in that users data being encrypted ...
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Wed Mar 22, 2017 12:33 am    Post subject: Reply with quote

As well, the malware could have added a file to a directory and made it executable, set up for some future attack with the same security hole. Something in /etc/init.d for example, or some config file snippet that gets added to apache because of its presence in a conf.d folder which turns on a feature set and thereby opens a hole.

Or it could be any number of other things.
Back to top
View user's profile Send private message
C5ace
Guru
Guru


Joined: 23 Dec 2013
Posts: 472
Location: Brisbane, Australia

PostPosted: Wed Mar 22, 2017 12:34 am    Post subject: Reply with quote

eohrnberger wrote:
NeddySeagoon wrote:
eohrnberger,

So the root kits are still installed?


Don't think there are any. rkhunter and chrootkit both come up empty. If you know of another scanner, I'll run it.

I'm keeping my eye on it. Might not have installed one. I suppose that if I were to recompile everything, wouldn't that flush out any altered binaries?

I'm still learning (aren't we all always all the time?), and this is a learning experience too.



I had last year a similar problem caused by a macro virus in MS Excel running in Wine.
Tried emerge @world without success, My final solution was to run 'dd if=/dev/random of=/dev/sda' from a SystenRescue CD and re-install Gentoo, Wine and the other software, except for MS Office.
Back to top
View user's profile Send private message
ct85711
Veteran
Veteran


Joined: 27 Sep 2005
Posts: 1791

PostPosted: Wed Mar 22, 2017 12:35 am    Post subject: Reply with quote

One thing you need to remember is that portage ONLY knows of files it installed. This means it won't know of all the other files that was created during run-time or through some other action. Portage will know of a file if it tries to install an file that already exists on the system (i.e. a file collision). The other thing you need to remember is that there is no rule saying on where an executable file must be located at, to would have to look at in every folder for any executable file (which may be hidden).

Rootkit scanners generally look for patterns of known rootkits (like virus scanners). The point we are getting at, is there is no way to be 100% certain that your system is clean. Now if you can again trust an system that is/was known to have been compromised again is your choice. For a lot of us, including me, the only we can trust it again is by wiping and reinstalling, so that the system is back in an known state.
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Wed Mar 22, 2017 1:28 am    Post subject: Reply with quote

Again I am not advocating using root by any means. But what's good for the goose is good for the gander: if the code is good such that you can't escape out into to a user account, and because root is also a user, you also can't escape out to root either.

So all software needs to be vetted? So you want all binaries to be signed as proof that they are vetted? Do we need some sort of Android and central signing for everything such that all binaries are signed for authenticity too? Who gets to sign the keys? What if you keep your keys and some exploit finds them or bypasses them?

And what difference does it make between OS (including Windows) and VM hypervisor code - on the same token you can also call web browsers and adobe-flash "authorized code" by your definition because VM code runs on top of an OS, so why not a web browser? They are all software and they all can have bugs. What about OS bugs, some way that protects against dirtyc0w? Should that copy on write code been more carefully vetted? Why wasn't it correct? I don't claim there necessarily is a solution, but if the code was simpler and people were more careful when writing code, less of these things would happen. Adobe-flash is clearly a travesty, Macromedia or whoever wrote the code did not think through of all the possible ways to exploit the code.

Also, even adobe-flash was supposed to provide a level of protection against the "unauthorized code" coming from the internet, otherwise people should just distribute random binary plugins to run on everyone's computers which clearly isn't savory. Adobe-flash should only allow doing certain well defined tasks: drawing in your browser, playing sounds over your speakers, possibly download video or audio, perhaps work with cookies, and maybe some other stuff. None of these is "allow unauthorized code to edit your /etc/passwd or ~/.bash_profile" and is no different than the kernel giving up root access when racing a copy on write situation causes privilege escalation or a VM damaging the host machine when running exploitive code.

If you're claiming that I'm advocating for running only as root, that is utterly false. The claim is that if we have ideal software with ideal humans, then running as root is no different than running unprivileged - a simple if/then relationship, and the constraint is not satisfied. To better the situation there needs to be reason or incentive for people to be less sloppy with writing software for other people - writing them such that they can be proven correct and not because the bean counter wants it out on XYZ date.

---

And agreed, the root cause of what caused the OP's issue has not been found. Adobe-flash is merely a "usual suspect" but we're simply blaming it again just because it was convicted in the past and not because we definitively proved it left the gate unlocked again. Agreed, reinstall is the only way to ensure that any contamination is gone. There are too many configuration files that need to be checked along with the questionable binaries and possibly contaminated package manager files as stated earlier. However I still am interested in forensics on the disk as a learning experience as to find out what really was the vector. The portage checksums at least is a starting point for what got changed (we know /etc/motd got changed so portage, as a sanity check, should report that got changed.)

---

C5ace, you were also running Excel in Wine as root? :( That would be a new one, a MS excel macro virus that targets wine in Linux...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Wed Mar 22, 2017 2:02 am    Post subject: Reply with quote

eccerr0r wrote:
Again I am not advocating using root by any means. But what's good for the goose is good for the gander: if the code is good such that you can't escape out into to a user account, and because root is also a user, you also can't escape out to root either.


No. Root is a special case of security. It is the equivalent of the Windows 'system' user, only with ownership. It's there because we need a way to maintain a system without giving crazy access to a normal user. The goose/gander rule does not apply.

Quote:

So all software needs to be vetted? So you want all binaries to be signed as proof that they are vetted? Do we need some sort of Android and central signing for everything such that all binaries are signed for authenticity too? Who gets to sign the keys? What if you keep your keys and some exploit finds them or bypasses them?


Absolutely not. If I find out that a sudoer on one of my systems -- even a noncritical system -- ran unsafe software as root then they will no longer be a sudoer on any of my systems and will no longer have access to any of my networks even as a guest. I've essentially fired IT staff because they ran a browser as root, and defended it to management by describing the kind of mayhem that can result. It is understood, meaning printed in system administrator manuals, that you don't run a @#$@ browser as root. You don't run ANYTHING as root which is not known to be safe.

Let me be crystal clear: If you stick a Raspberry Pi on one of my networks and run a browser on it as root, and I find out about it, you're fired. No second chance, no warning, end of discussion. Any administrator of any enterprise network would no doubt do exactly the same thing.

The root user is there because it's impossible to vet all code. It's there because some code you DO NOT WANT a normal user to have access to, under any circumstances. The written rule is that only trusted code be executed by root, and the rule is written in human terms not in code because an administrator or collection of administrators can create or find software they trust to be run as root, which cannot be dictated from some operating system vendor IT department on another continent.

Quote:

And what difference does it make blah blah blah...
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Wed Mar 22, 2017 2:08 am    Post subject: Reply with quote

It is not the role of software engineers to babysit idiots. Administrators of systems are supposed to be concerned with security and smart enough to not do stupid shit. Everything you've said regarding geese and ganders is completely irrelevant. Go look up how many services strongly recommend that they be run as a non-root user either in part or in their entirety. Apache httpd runs a single thread as root because of the port 80 limitation, and runs everything else as a non-root user with minimal permissions. Why? Because the goose and gander rule does not apply to root.

Edit: To complete the thought,

No server software vendors in the UNIX world, either free software or commercial software, have tried to force all software to be vetted so it can be run as root. It's obvious to anyone why such a user is needed, and why it needs to circumvent normal security. It's also obvious that not all software is safe for that user to execute.

Even if you can vet firefox for example, you go to a typical web site with advertising and all bets are off. Those sites sell ad space to customers who provide their own content from their own servers. Those customers also have customers, and those customers of customers have their own servers. Each ad can contain javascript or a java applet or who knows what. Or simply have an enticing ad that convinces the user to click a button which downloads a file which was signed by a key from a registered vendor but stolen and not yet known to be compromised,
ad nausea infinitum.

You keep focusing on bugs. Software has bugs, and while we can work to step on them the fixes and new features is always adding more bugs.

The thing that should make what I'm saying obviously correct is not about bugs, it's about deliberate malware. It's about bad people trying to get into your system for whatever their own ends might be.

It's not even theoretically possible to vet all of a Linux distro's software repository to the degree necessary to allow root to run everything with any assurance of bug-free operation. The software is updating too fast for that. How much less possible is it for all of the Internet to be vetted? Every javascript line, every clickbait link, every software download, every excel spreadsheet, every Word document? Even accidental mistakes would be insanely overwhelming, and deliberate malware takes it to a new level of impossible.


Last edited by 1clue on Wed Mar 22, 2017 3:14 am; edited 2 times in total
Back to top
View user's profile Send private message
eohrnberger
Apprentice
Apprentice


Joined: 09 Dec 2004
Posts: 240

PostPosted: Wed Mar 22, 2017 2:12 am    Post subject: Reply with quote

I'm not disagreeing with anyone, WRT the only way to be sure is to wipe and reload. I may end up there. I've had to a do a number of Windows systems like that.

True, there are quite a few config files on a Linux machine I've compared the system against the version controller copies of the config files, and it appears that none were altered, or trivial changes, such as adding the $ID tag (I think it was). Further, since comparing the content of the directories, i.e. file names as well as the file contents, against version control, I think would be a bit like tripwire in that regard. It will reveal any changes / additions (deletions too) in the /etc tree.

I'm intrigued by the idea of running a 'portage checksums' test.
Googled a bit, but didn't quite find the magic command line for that. Any references please?
Is this going to check the /usr/portage tree integrity, or the installed files integrity?
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Wed Mar 22, 2017 2:15 am    Post subject: Reply with quote

eohrnberger wrote:
I'm not disagreeing with anyone, WRT the only way to be sure is to wipe and reload. I may end up there. I've had to a do a number of Windows systems like that.

True, there are quite a few config files on a Linux machine I've compared the system against the version controller copies of the config files, and it appears that none were altered, or trivial changes, such as adding the $ID tag (I think it was). Further, since comparing the content of the directories, i.e. file names as well as the file contents, against version control, I think would be a bit like tripwire in that regard. It will reveal any changes / additions (deletions too) in the /etc tree.

I'm intrigued by the idea of running a 'portage checksums' test.
Googled a bit, but didn't quite find the magic command line for that. Any references please?
Is this going to check the /usr/portage tree integrity, or the installed files integrity?


The problem with the idea of portage checksums test is that many config files are generated after install and thus not in portage, and not included in the checksum.
Back to top
View user's profile Send private message
eohrnberger
Apprentice
Apprentice


Joined: 09 Dec 2004
Posts: 240

PostPosted: Wed Mar 22, 2017 2:27 am    Post subject: Reply with quote

1clue wrote:

The problem with the idea of portage checksums test is that many config files are generated after install and thus not in portage, and not included in the checksum.


OK, granted, but I think I have a handle on the config file part of that, and if we can detect an altered binary, that'd be the gain that I can see.

Heck, I'm willing to let the thing run all night and log to a file, check it out when I get back home from work. See if it detected any mismatches.
Back to top
View user's profile Send private message
1clue
Advocate
Advocate


Joined: 05 Feb 2006
Posts: 2569

PostPosted: Wed Mar 22, 2017 2:30 am    Post subject: Reply with quote

eohrnberger wrote:
1clue wrote:

The problem with the idea of portage checksums test is that many config files are generated after install and thus not in portage, and not included in the checksum.


OK, granted, but I think I have a handle on the config file part of that, and if we can detect an altered binary, that'd be the gain that I can see.

Heck, I'm willing to let the thing run all night and log to a file, check it out when I get back home from work. See if it detected any mismatches.


It's an interesting exercise, but real security is not about what you know. It's about what the other guy knows.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Wed Mar 22, 2017 4:55 am    Post subject: Reply with quote

eohrnberger wrote:
I'm intrigued by the idea of running a 'portage checksums' test. Googled a bit, but didn't quite find the magic command line for that. Any references please? Is this going to check the /usr/portage tree integrity, or the installed files integrity?

eohrnberger ... as I think was mentioned earlier in the thread, this is no guarentee (the checksums exist on the same filesystem as the tampered files ... and so may be considered equally suspect). That said, here are a few examples:

Code:
# equery belongs -e /usr/bin/qcheck
 * Searching for /usr/bin/qcheck ...
app-portage/portage-utils-0.62 (/usr/bin/qcheck -> q)
# qcheck -C --quiet > qcheck.lst

Code:
# equery belongs -e /usr/bin/equery
 * Searching for /usr/bin/equery ...
app-portage/gentoolkit-0.3.3 (/usr/bin/equery -> ../lib/python-exec/python-exec2)
# equery belongs -e /usr/bin/qlist
 * Searching for /usr/bin/qlist ...
app-portage/portage-utils-0.62 (/usr/bin/q)
# equery -NC check $(qlist -IC) 2> equery-check.lst

... or a more homebrew (and inefficent) approach:

Code:
# find /var/db/pkg -name "CONTENTS" -exec awk '/^obj\s/{print $3,$2}' {} + | md5sum -c 2>/dev/null | grep -v "OK" | sort

... app-portage/portage-utils are generally faster in my experience (which I would expect, given they are C, rather than python, or pipes).

best ... khay
Back to top
View user's profile Send private message
Goverp
Veteran
Veteran


Joined: 07 Mar 2007
Posts: 1972

PostPosted: Wed Mar 22, 2017 7:43 am    Post subject: Reply with quote

eohrnberger wrote:
NeddySeagoon wrote:
eohrnberger,

So the root kits are still installed?


Don't think there are any. rkhunter and chrootkit both come up empty.
...

AFAIK, rkhunter isn't like a virus scanner, it doesn't look for known (or unknown) rootkits; it (a) looks for symptoms such as incorrect security settings, and (b) compares important system files for changes from a previous baseline. That baseline is created in the previous rkhunter run. So if you've only just installed it and run it, its baseline is the rooted system, and you'll get no warnings. Indeed, it would report a change if you succeeded in removing the rootkit! Anything else is about dodgy configuration.
I've no idea if that's true about chrootkit.
_________________
Greybeard
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9645
Location: almost Mile High in the USA

PostPosted: Wed Mar 22, 2017 9:13 am    Post subject: Reply with quote

1clue - I can see that you're really into viciously enforcing rules, which is reasonable if the software isn't completely understood, which has its base but still very arbitrary. It's clear all the examples you're giving because we know each of them have exhibited bugs in the past in both the actual server/program AND poor user configuration, both of which will benefit from privilege separation. A lot of application developers are suggesting privilege separation simply because they are not willing to find and fix bugs that can cause privilege escalation, mostly because they know it's becoming too difficult to know every possibility (and thus not "correct by design"). And again, it doesn't matter if it's escalating from a "VM" environment like HTML to running arbitrary machine code on the machine as a regular user or root, it's still a security hole that needs to be fixed.

But what really should be the lower bound? Why not run 'ls' as a unprivileged user as well, why does it get an OK for being run as root. Granted 'ls' is simple enough to be fairly well checked such that specially crafted directories with bad filenames will never cause buffer overflow and cause 'ls' to run arbitrary code. Why shouldn't other software also be subject to similar scrutiny, even if it's much harder? And if it were carefully inspected, why shouldn't it get the same treatment like 'ls' is trusted by most people? After all, after 'ls' grabs disk blocks and inode contents getting past permissions, it no longer needs root to process and print on your display - yet nobody is running it under privilege separation when it too could also harbor bugs.

Now curl/wget must also be run under privilege separation by your rules too? I suspect so, but I do I wonder how many people wouldn't bat an eye before running wget as root when they wouldn't and shouldn't run firefox as root.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
cboldt
Veteran
Veteran


Joined: 24 Aug 2005
Posts: 1046

PostPosted: Wed Mar 22, 2017 11:39 am    Post subject: Reply with quote

rkhunter has a few functions built in. One is similar to what you describe, file permissions, hashes, sizes, etc for a collection of 170 or so files that are in rkhunter's "repertoire" I see this as a sort of "limited tripwire" functionality.

rkhunter ALSO has a list of files and techniques that are often used by rootkits, above and beyond the short list of expected files, often taken over by a rootkit. This list is like a typical virus hunter, in that it only knows about the things it is looking for, and will overlook any hiding place not in its list.

I run both, rkhunter and tripwire, on a daily basis. Each tool has strengths and weaknesses. On the ultimate issue, once compromised, if I didn't know the vector and the attack, I would not trust the machine, even though I make an effort to keep a very close watchful eye on it.

Edit to add ...

Code:
 rkhunter --list tests

Current test names:
    additional_rkts all apps attributes avail_modules deleted_files
    filesystem group_accounts group_changes hashes hidden_ports hidden_procs
    immutable known_rkts loaded_modules local_host malware network
    none os_specific other_malware packet_cap_apps passwd_changes ports
    possible_rkt_files possible_rkt_strings promisc properties rootkits running_procs
    scripts shared_libs shared_libs_path startup_files startup_malware strings
    suspscan system_commands system_configs trojans

Grouped test names:
    additional_rkts => possible_rkt_files possible_rkt_strings
    group_accounts  => group_changes passwd_changes
    local_host      => filesystem group_changes passwd_changes startup_malware system_configs
    malware         => deleted_files hidden_procs other_malware running_procs suspscan
    network         => hidden_ports packet_cap_apps ports promisc
    os_specific     => avail_modules loaded_modules
    properties      => attributes hashes immutable scripts
    rootkits        => avail_modules deleted_files hidden_procs known_rkts loaded_modules other_malware possible_rkt_files possible_rkt_strings running_procs suspscan trojans
    shared_libs     => shared_libs_path
    startup_files   => startup_malware
    system_commands => attributes hashes immutable scripts shared_libs_path strings
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page Previous  1, 2, 3, 4, 5  Next
Page 3 of 5

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum