Security

Things related to computer security in some way or another.

Viewpoint: The Attack on Sony

2014/12/21:
I am redacting my original post because while I strongly believe it is misguided and unhelpful what is being claimed (by the US government), I think also that the way I addressed this was was not helpful, either. Certainly it detracts from my main point. While I often will keep things I’ve written, as I put it in my about section, I also believe in fixing mistakes where necessary. I’ve also noted that some of my writing will come off as a rant or otherwise aggressive and that I fix it where I can (and I always try to get a point across but often fail because of aggressiveness, whether it was intentional or not – yesterday’s aggressiveness was not intentional by any means). It is interesting to note that the other day I actually went to write something about this issue and I decided to delay it because I felt I was not in the right mindset. Apparently I was still not in the right mindset, yesterday. Of course, even though I’m fixing the post, that does not at all mean what was public will not remain public: once on the Internet it is as good as on the Internet (and even if all references were removed it still doesn’t mean there isn’t a single person who saw it and potentially captured it: I’ve done exactly this and I know others have too). But I still believe in taking responsibility and addressing mistakes where possible, and addressing means fixing the issue(s). So with that, my modified view on the attack on Sony. Do note that the title could very well be better worded (and this is how it was yesterday, too). I’m not sure how else to word it so it’ll suffice.


The last time, Sony brought (after the ‘first’ – the quotes are important here – attack) brought in a security professional. Yet, while some might find it ironic (it isn’t) there was another attack. First tip of old: if you consider security after an attack, or after deployment (e.g. in software development), then you’re behind at best and you may very well be too late, too. Second tip of old: in general, notwithstanding certain (rare and still not well advised) cases, if your network was compromised (there is one thing to consider here[1]), the only safe way is to start all over with improved policies, based on what you learned from the attack. There is the reason I quoted ‘first': while it isn’t a guarantee (by all means, given what was claimed, it could have been individual but that makes it even worse, not better!) I wouldn’t be surprised if they had left a backdoor or otherwise hadn’t truly left. This very bit is a common thing, isn’t it? Why would it not be? While some do it for a challenge (and I would argue this is far less common these days) there is this simple fact that they use the breached network for many things. This includes bouncing (and this isn’t counting bouncing off of proxies). This brings me to the first real point about the ‘evidence': IP address.

I could elaborate on why IP address doesn’t mean much, certainly not for proof, but I think I have a better way. If you were to lose your mobile phone, or if someone were to steal it, who is the rightful owner? You? Yes. Okay, so what happens if they then use that phone to pull pranks, make threatening calls, or otherwise abuse the fact it isn’t their phone? Is it your fault, is it your responsibility? No? Then what makes you think IP address is any different? It isn’t. There’s far too many possibilities. Worse is that even if the IPs are from North Korea (which I haven’t seen them nor do I really care – it is irrelevant to the point) it doesn’t mean it is state sponsored. It also doesn’t mean it isn’t. And that is exactly the problem: it is speculation and until it is actually confirmed it may as well be slander. I’m sorry to say that being confident (as at least one US official has stated) doesn’t equate to reality, most certainly not 100% of the time; I know this personally as does anyone who has been delusional but is not currently having said delusion: I was confident that traffic signals were spying on me and me alone as one example. Yes, I’m able to admit this publicly. Why? Why not is better asked. While I am by no means suggesting they are delusional here, my point is that being confident does not equate to reality (and this applies to those who are not delusional). While this is not necessarily any better of an example, this is something that specifically makes my point that many things are not as they seem: Mirror Lake in Yosemite National Park, to name one of several (I seem to remember there is one in Canada, too). This should all be kept in mind when dealing with accusations. I know, I know, there is the addition to IP that the attack ‘looks’ similar to a previous attack: it is still speculation until proven otherwise. Again I’m going to give a non-technical example: some countries purchase aircraft from other countries. But that doesn’t mean the jet flying over a country IS the country that manufactured the jet. Similarly, some countries share flags while others have flags that are similar to another. That doesn’t mean that the countries are the same.

There’s also been the claim that this attack is unprecedented. I don’t think so. Neither was it impossible to prevent. Yes, there is always someone who can best another, but that doesn’t mean there is never room for improvement; there is always room for improvement! Always. Just like some attacks are not prevented, many more are. But to throw blame elsewhere, and to not address the real problem is a problem itself. This is not the first time Sony has come under attack. They also aren’t the only one to be compromised more than once. I know for a fact that Kevin Mitnick, what many would call a notorious hacker (and he calls himself a hacker too, or at least he did) fell prey to some that bested his him and consequently compromised his network. His company after his release from federal prison (2001 comes to mind as his release date but I’d have to check to confirm). In addition, the reason he was caught the second time around (indeed his arrest in the mid 1990s was not his first time being in trouble with the law) was because someone bested him then, as I recall someone he had attacked himself. I certainly do not call him a hacker, not even by the media’s definition of hacker: he is excellent at social engineering, that much is true. Regardless, this was not the first time Sony was compromised. You would think that someone like Mitnick would be able to not fall prey here, given his title. But then it is easier to forgive a company like Sony. The only thing that matters is (and I really hope they do exactly this) they re-evaluate their policies and implement the improvements. This goes for every entity. The only true mistake is not learning from your mistakes. The only failure is not learning from your supposed failures; we all make mistakes and none of us succeed in everything.

I would like to leave with some final thoughts: The group that claimed responsibility for the attack on Sony, GOP – Guardians of Peace – only started to use the film about North Korea’s leader after it was suggested it was related. Because of this, and since North Korea was enraged about the film (I have some thoughts here, which I share below[2]) prior to the attack, it was now North Korea’s fault. This is a fallacy. A fallacy is illogical deduction and even if they are responsible, the logic used as above, is flawed.

In the end, IP address, similarity in attack and other such things are not indicative of anything, not indicative unless you wish to believe only what you want to believe. As a final example: Robert Tappan Morris, indeed the author of the infamous ‘Internet Worm’, aka ‘The Morris Worm’, made his worm appear to come from a different university than his. This was to throw the authorities off his trail. Due to mistakes on his part, however, the worm brought the affected machines to their knees. The effects of it were out and he was tracked down. Combine this with the fact that (for instance) many viruses, worms, trojan horses, backdoors and otherwise malware, are families of malware (which might not be written by the same person and indeed this is the case), this shows too that similarities does not imply equivalence (nor same source).


[1] Does web defacement constitute network being compromised? It could. But it could also not be. File integrity checks would help determine this here (but is not perfect either, if the attacker gets root access).  It is true that with content management systems, a web defacement makes it easier and not requiring compromising the system itself (especially true if there is a configuration in the web files that specifically deny the CMS from modifying those files; i.e. you can only use the interface for the content and nothing else). In the end, the only safe way (but mind the fact that depending on how long ago the attack was (and attack implies original access, not defacement!) backups could also have a backdoor or indeed anything else). On this latter bit, backups: this is one of many reasons that the backup volume should either only be mounted when backing up (or restoring) or made immutable (except during writing to the volume). Another reason is user error (and yes, as I’ve made clear, administrators count as users): if a command you run, a script you write or something else you run (or is affected by a bug) goes badly, what if you wipe out (or damage) your backup? (Redundant backup isn’t necessarily the answerany more than redundant storage; the point of backup is having it in multiple locations (e.g. off-site (no, this does not include the cloud or anything you do not have complete control over!) and on-site), not having multiple copies: the difference is subtle but something that should be understood).

[2]As for North Korea being enraged. The fact remains that North Korea and the United States are not on good terms. So when you consider the film’s plot, and you consider the different culture, it isn’t all that surprising, is it? And you can see how it can provoke them. The subject of free speech (and more specifically freedom of expression) is usually brought up and indeed it is here too. Unfortunately though, like many things in this world, it is very often taken too far. It is especially taken too far when defending someone or something that (you) agree with (or sympathise with). It is also defended when you disagree or dislike that which is offended or upset by the expressions. As something I am unfortunately familiar with far too well, many people excuse bullies (even minor bullying is wrong but minor bullying develops further in to moderate to extreme to beyond extreme) as “kids will be kids”. The problem is, you can only abuse someone so much, before they snap. So yes, kids will be kids – until victims of bullying – also kids – get revenge on bullies. Then the kids are now horrible, and the “kids will be kids” is no where to be seen or heard. I am eternally grateful that there isn’t a violent streak in me, because I would have been another example of the above. I did get revenge in ways, but I did it subtly and non-violently. I also enjoyed outsmarting them, making them look like fools without them even knowing just how much so. The reality is violence doesn’t solve anything, at least not in positive ways, but if you subject someone to abuse, when they get revenge (which indeed includes violence), it is natural and expected. To explain this, there is a phenomenon called ‘identifying with the aggressor’. This is exactly why domestic abuse runs in families: the victims are not in power, are helpless and suffer because of it. But they also see that in order to gain control, which means to stop the abuse, they can become abusive themselves. So continues a vicious cycle…

The Secret: Trust and Privacy

First, as is typical of me, the title is deliberate but beyond the pun it actually is an important thing to consider, which is what I’m going to tackle here. The secret does indeed imply multiple things and that includes the secret to secrets, the relation between privacy and security and how trust is involved in all of this. I was going to write a revision to my post about encryption being important (and I might still to amend one thing, to give credit to the FBI boss about something, something commendable) but I just read an article on the BBC that I feel gives me much more to write about. So let me begin with trust.

Trust is something I refer to a lot, in person and here and pretty much everywhere I write about something that considering trust is a good thing. Indeed, trust is given far too easily. As I have outlined before, even a little bit of trust – seemingly harmless – can be abused. Make no mistake: it is abused. The problem is if you’re too willing to trust how do you know when you’ve been too trusting? While I understand people need to have some established trust with in their social circles, there are some things that do not need to be shared and there are things that really should not be entrusted to anyone except yourself, and that potentially includes your significant other. Computer security is something that fits here. Security in general is. The other problem is: ignorance. Ignorance is not wrong but it does hurt and if you don’t understand the risks of something (which I would argue the fanatical and especially the younger Facebook and other social media users, are) is risky, how do you proceed? For kids it is harder as it is known that kids just do not seem to understand that they are not immortal, not immune to things that really are quite dangerous. However, if you are too trusting with computers, you are opening a – yes, I know – a huge can of worms, and it can cause all sorts of problems (any of taking complete ownership of your computer, monitoring your activities which can lead to identify theft, phishing and many other things, from …). The list of how many issues that granting trust can lead to, is, I fear, unlimited in size. It is that serious. You have to find a balance and it is incredibly hard to do, no matter how experienced you are. I’ve made the general ideas clear before, but I don’t think I’ve actually tackled this issue with privacy and secrecy. I think it is time I do that.

In the wake of the Edward Snowden leaks, many more people are concerned for their privacy. While they should have always been concerned, it doesn’t really change the fact that they are now at least somewhat more cautious (or many are, at least). I have put this thought to words in multiple ways. The most recent is when I made a really stupid mistake (leading to me – perhaps a bit too critical but the point is the same – awarding myself the ID 10 T award), all because I was far more exhausted than I thought. Had I been clear I wouldn’t have had the problem. But I wasn’t clear headed and how could I know it? You only know it once it is too late (this goes for driving too and that makes it even more scary because you could hurt someone else, whether someone you care about or someone you don’t even know). The best way to word this is new on my part: Despite the dismissal people suggest (“what you don’t know cannot hurt you” is 100% wrong), the reality is this: what you don’t know can hurt you, it likely will and worse is it could even kill you! This is not an exaggeration at all. I don’t really need to get in to examples. The point is these people had no idea to what extent spying was taking place. Worse still they didn’t suspect any thing of the sort. (You should actually expect the worst in this type of thing but I suppose that takes some time to learn and come to terms with.) Regardless, they do now. It has been reported – and this is not surprising really, is it? – that a great population of the United States are now very concerned with privacy, have much less trust in the governments (not just the US government, folks – don’t fall for the trap that only some countries do it, you’re only risking harm to yourselves if you do!) in privacy. What some might not think of (although certainly more and more do and will over time), and this is something I somewhat was getting at with the encryption post, is this: If the NSA could not keep secret (and that is ironic itself, isn’t it? Very ironic and to the point of hilarity) their own activities (own is keyword number one) secret (and safe!) then how can you expect them to keep YOUR (keyword number two) information secret and safe? You cannot. There is no excuse for it: they aren’t the only ones, government, corporations, it really doesn’t matter, too many think of security after the fact (and those that do think of it in the beginning are still prone to making a mistake or not thinking of all angles… or a bug in a critical component of their system, leads to the hard work in place, being much less useful or relevant). The fact they are a spying agency and they couldn’t keep that secret is to someone who is easily amused (like myself), hilarious. But it is also serious isn’t it? Yes, and it actually strengthens (or further shows) my point that I will get to in the end (about secrets). To make matters worse (as hard as that is to fathom), you have the increase (and I will tell everyone this, this is not going to go away and it is not going to be contained – no, it will only get worse) in point of sale attacks (e.g. through malware) that has in less than a year led to more corporations having major leaks of confidential information than I would like to see in five or even ten years. This is the number of corporations – the amount of victims is millions (per corporation, even)! This information includes credit card details, email addresses, home addresses, … basically the information that can help phish you even enough to steal your identity (to name one of the more extreme possibilities). Even if they don’t use it for phishing you would be naive to expect them to not use the stolen information.

I know I elaborate a lot and unfortunately I haven’t tied it all together yet. I promise it is short, however (although I do give some examples below, too, that do add up in length). There is only one way to keep something safe, and that is this: don’t share it. The moment you share something with anyone, the moment you write it down, type it (even if you don’t save it to disk), do some activity that is seen by a third party (webcam or video tape, anyone?), it is not a secret. While the latter (being seen by camera) is not always applicable, the rest is. And what good is a secret that is no longer a secret? Exactly: it is no longer secret and therefore cannot be considered a secret. Considering it safe because you trust someone – regardless of what you think they will do to keep it safe and regardless of how much you think you know them – is a dangerous thing (case in point: the phenomenon called, as I seem to remember, revenge porn). In the end, always be careful with what you reveal. No one is immune to these risks (if you are careless someone will be quite pleased to abuse it) and I consider myself just as vulnerable exactly because I AM vulnerable!

On a whole, here is a summary of secrets, trust and security: the secret to staying safe and as secure as possible, is to not give out trust for things that need not be shared with anyone in the first place. If you think you must share something, think twice really hard and consider it again: you might not need to no matter how much the person (or entity) claims it will benefit you. Do you really, honestly, need to turn your thermostat on by your computer or phone? No, you do not and some thermostats have been exposed to have security flaws (in recent times). It isn’t that important. What might seem to be convenient might actually be the opposite in the end.

Bottom line there is this: If someone insists you need something from them or their company, they do not have you in your best interest! Who is anyone else to judge whether you need their service or product?

A classic example and a funny story where the con-artist was exposed: If you go to a specialist to have an antique valued and they offer to buy it you should never do it because if they tell you something is worth X it is one thing. It is however another thing entirely to tell you it is worth X and then offer to buy it from you. The story: years ago, my mother caught a smog-check service in their fraud (and they were consequently shutdown for it, as should be) because despite being female – and therefore what the con-artist thought would be easy prey, nice try loser – she is incredibly smart and he was a complete moron. He was so moronic that despite my mother being there listening to the previous transaction between the customer (“victim”) and himself, he told my mother the same story: you have a certain problem and I’ll charge X to fix it. The moron didn’t even change the story at all – he used it word for word, same problem, same price, right in front of my mother. In short: those telling you the value of something and then telling you they’re willing to buy/fix/whatever, are liars. Some are better liars but they’re still liars.

It is even worse when they are (example) calling you – i.e., you didn’t go to them! Unsolicited tech support calls, anyone? Yes, this happened not long ago. I really pissed off this person by turning the tables on him. While what I did is commendable (As he claimed, I wasting his time which means he lost time he could be cheating someone else) do note that some would have instead fallen victim and the reason he kept up until I decided to play along (and make a fool of him, as you’ll see if you read), is exactly because they are trained: trying to manipulate, trying to keep me on the line as long as possible (which means more time to try to convince me I need their service), and they only wanted to cheat me out of money (or worse: cause a problem with my computer that they were claiming to fix). Even though I got the better of them (as I always have) and to the point of him claiming I was wasting HIS time, they will just continue on and try the next until they find a victim. It is just like spam: as long as it pays they will keep it up. People do respond (directly and indirectly) to spam and it will not end because of this, as annoying as it may be. Again, if some entity is telling you you need their service or product, it is not with your best interest but their interest! That is undeniable even if you initially went to them, if they are insisting you need their product or service, they are only their to gain and not help. This is very different from going to a doctor and them telling you something serious (although certainly there are quacks out there, there is a difference and it isn’t too difficult to discern). Always be thinking!

Encryption IS Critical

I admit that I’m not big on mobile phones (and I also admit this starts out on phones but it is a general thing and the rules apply to all types of nodes). I’ve pointed this out before, especially with regards to so-called smart technology. However, just because I personally don’t have much use for it, most of the time, does not mean that the devices should not be as secure as possible. Thus, I am firstly, giving credit to Apple (which all things considered is exceptionally rare) and Google (which is also very rare). I don’t like Apple particularly because of Steve Jobs’ arrogance (which I’ve also written about) but that is only part of it. At the same time, I do have fond memories of the early Apple computers. As for Google, I have serious issues with them but I haven’t actually put words to it here (or anywhere actually). But just because I don’t like them does not mean they can never do something right or that I approve of. To suggest that would be me being exactly as I call them out for. Well, since Apple and Google recently suggested they were to enable encryption by default for iOS and Android, I want to commend them for it: encryption is important.

There is the suggestion, most often by authorities (but not always as – and this is something I was planning on and I might still write about – Kaspersky showed not too long ago when they suggested similar things), that encryption (and more generally, privacy) is a problem and a risk to ones safety (and others’ safety). The problem here is that they are lying to themselves or they are simply ignorant (ignore the obvious please, I know it but it is besides the point for this discussion). They are also risking the people they claim to want to protect and they also risk themselves. Indeed, how many times has government data been stolen? More than I would like to believe and I don’t even try to keep track of it (statistics can be interesting but I don’t find the subject of government – or indeed other entity – failures all that interesting. Well, not usually). The problem really comes down to this, doesn’t it? If someone has access to your or another person’s private details, and it is not protected (or poorly protected), then what can be done to you or that other person if someone ELSE gets that information? Identify theft? Yes. Easier time gathering other information about you, who you work for, your friends, family, your friends’ families, etc.? Yes. One of the first things an attacker will do is gather information because it is that useful in attacks, isn’t it? And yet, that’s only two issues of many more, and both of those are serious.

On the subject of encryption and the suggestion that “if you have nothing to hide you have nothing to fear”, there is a simple way to obliterate it. All one needs to do is ask a certain (or similar) question and explanation following, directed at the very naive and foolish person (Facebook founder has suggested similar, as an example). The question is along the lines of: Is that why you keep your bank account, credit cards, keys, passwords, etc., away from others? You suggest that you shouldn’t have a need to keep something private because you have nothing to hide unless you did something wrong (and so the only time you need to fear is when you are in fact doing something wrong). But here you are hiding something (that you wouldn’t want others knowing, in other words, and with your logic it follows that you did something wrong), yet here you are hiding your private information. The truth is that if you have that mentality, you are either lying to yourself (and ironically hiding something from yourself and therefore not exactly following your suggestion) or you have hidden intent or reasons to want others information (which, ironically enough, is also hiding something – your intent). And at the same time,  you know full well that YOU do want your information private (and YOU should want it private!).

But while I’m not surprised here, I still find it hard to fathom how certain people, corporations and other entities still think strong encryption is a bad thing. Never mind the fact that many high-profile cases of criminal data confiscated by police has been encrypted and yet revealed. Never mind the above. It is about control and power and we all know that the only people worthy of power are those who do not seek it but are somehow bestowed with it. So what am I getting at? It seems that, according to the BBC, the FBI boss is concerned about Apple’s and Google’s plans. Now I’m not going to be critical of this person, the FBI in general or anything of the sort. I made aware in the past that I won’t get in to the cesspool that is politics. However, what I will do is remark on something this person said but not remark on it by itself. Rather I will refer to something most amusing. What he said is this:

“What concerns me about this is companies marketing something expressly to allow people to place themselves beyond the law,” he said.

“I am a huge believer in the rule of law, but I am also a believer that no-one in this country is beyond the law,” he added.

But yet, if you look at the man page of expect, which allows interactive things that a Unix shell cannot do by itself, you’ll note the following capability:

  • Cause your computer to dial you back, so that you can login without paying for the call.

That is, as far as I am aware, a type of toll fraud. Why am I even bringing this up, though? What does this have to do with the topic? Well, if you look further at the man page, you’ll see the following:

ACKNOWLEDGMENTS
Thanks to John Ousterhout for Tcl, and Scott Paisley for inspiration. Thanks to Rob Savoye for Expect’s autoconfiguration code.

The HISTORY file documents much of the evolution of expect. It makes interesting reading and might give you further insight to this software. Thanks to the people mentioned in it who sent me bug fixes and gave other assis‐
tance.

Design and implementation of Expect was paid for in part by the U.S. government and is therefore in the public domain. However the author and NIST would like credit if this program and documentation or portions of them are
used.
29 December 1994

I’m not at all suggesting that the FBI paid for this, and I’m not at all suggesting anyone in the government paid for it (it is, after all, from 1994). And I’m not suggesting they approve of this. But I AM pointing out the irony. This is what I meant earlier – it all comes down to WHO is saying WHAT and WHY they are saying it. And it isn’t always what it appears or is claimed. Make no mistake people, encryption IS Important, just like PCI compliance, auditing (regular corporation auditing of different types, auditing of medical professionals, auditing in everything), and anyone suggesting otherwise is ignoring some very critical truths. So consider that a reminder, if you will, of why encryption is a good thing. Like it or not, many humans have no problem with theft, no problem with manipulation, no problem with destroying animals or their habitat (Amazon forest, anyone?). It is by no means a good thing but it is still reality and not thinking about it is a grave mistake (including indeed literally, and yes, I admit that that is pointing out a pun). We cannot control others in everything but that doesn’t mean we aren’t responsible for our own actions and ignoring something that risks yourself (never mind others here) places the blame on you, not someone else.

shell aliases: the good, the bad and the ugly


2014/11/11:
I erroneously claimed that the -f option is required with the rm command to remove non-empty directories. This is only a partial truth. You need -r as that is for recursion which traversing a file system, it would traverse directories encountered, until there are no more directories found (and indeed file system loops can occur which programs do consider). But -f isn’t for non-empty directories as such but rather write-permission related. Specifically, in relation to recurse (-r), if you specify -r you’ll still be prompted whether to recurse in to the directory, if it is write-protected (or write-protected file in). If you specify -f, you will not be prompted. Of course, there’s other reasons you might not be able to remove the directory or any files in it, but that is another issue entirely. Furthermore, root need not concern themselves with write permission, at least in the sense that they can override it.


2014/10/07:
Please observe the irony (that actually further proves my point, and that itself is ironic as well) that I suggest using the absolute path name and then I do not (with sed). This is what I mean by I am guilty of the same mistakes. It is something I have done over the years: work on getting in to the habit (of using absolute paths) and then it slides and then it happens all over again. This is why it is so important to get it right the first time (and this rule applies to security in general!). To make it worse, I knew it before I had root access to any machine (ever), years back. But this is also what I discussed with convenience getting in the way with security (and aliases only further add to the convenience/security conflict, especially with how certain aliases enable coloured output or some other feature). Be aware of what you are doing, always, and beware of not taking this all to heart. (And you can bet I’ve made a mental note to do this. Again.) Note that this rule won’t apply to shell built-ins unless you use the program too (some – e.g., echo – have both). The command ‘type’ is a built-in, though, and it is not a program. You can check by using the command itself like (type -P type will show nothing because there is no file on disk for type). Note also that I’ve not updated the commands where I show how aliases work (or commands that might be aliased). I’ve also not updated ls (and truthfully it probably is less of an issue, unless you are root, of course) but do note how to determine all ways a command can be invoked:

$ type -a ls
ls is aliased to `ls --color=auto'
ls is /usr/bin/ls

This could in theory could be only for Unix and its derivatives, but I feel there are similar risks in other environments. For instance, in DOS, extensions of programs had a priority so that if you didn’t type ‘DOOM2.EXE’ it would check – if I recall correctly, ‘DOOM2.BAT’ and ‘DOOM2.COM’ and then ‘DOOM2.EXE’. I don’t remember if that is the exact order but with no privilege separation you had the ability to rename files so that it if you wanted to write a wrapper to DOOM2 you could do it easily enough  (I use DOOM2 in the example because not only was it one of my favourite graphical computer games, one I beat repeatedly I enjoyed it so much, much more than the original DOOM… I also happened to write a wrapper for DOOM2 itself, back then). Similarly, Windows doesn’t show extensions at all (by default, last I knew anyway) and so if a file is called ‘doom.txt.exe’ then double clicking on it would actually execute the executable instead of opening a text file (but the user would only see the name ‘doom.txt’). This is a serious flaw in multiple ways. Unix has its own issues with paths (but at least you can redefine them and there IS privilege separation). But it isn’t without its faults. Indeed, Unix wasn’t designed with security in mind and that is why so many changes have been implemented over the years (the same goes for the Internet main protocols – e.g., IP, TCP, UDP, ICMP – as well as other protocols at say, the application layer – all in their own ways). This is why things are so easy to exploit. This time I will discuss the issue of shell aliases.

General idea for finding the program (or script or…) to execute is also a priority. This is why when you are root (or using a privileged command) you should always use a fully-qualified name (primarily known as using the absolute file name). It is arguably better to always do this because, what if someone modified your PATH, added a file in your bin directory, updated your aliases, … ? Now you risk running what you don’t intend to. There is a way to determine all the ways it could be invoked but you should not rely on this, either. So the good, then the bad and then the ugly of the way this works (remember, security and convenience conflict with each other a lot, which is quite unfortunate but something that cannot be forgotten!). When I refer to aliases understand that aliases are even worse than the others (PATH and $HOME/bin/) in some ways, which I will get to at the ugly.


THE GOOD


There is one case where aliases are fine (or at least not so bad as the others; the others is when you use options). It isn’t without flaws, however. Either way: let’s say you’re like me and you’re a member of the Cult of VI (as opposed to the Church of Emacs). You have vi installed but you also like vim features (and so have it installed too). You might want vi in some cases but vim in others (for instance, root uses vi and other users use vim, contrived example or not is up to your own interpretation). If you place in $HOME/.bashrc the following line, then you can override what happens when you type the command in question as follows:

$ /usr/bin/grep alias $HOME/.bashrc
alias vi='vim'

Then typing ‘vi’ at the shell will open vim. Equally, if you type ‘vi -O file1 file2′ it will be run as ‘vim -O file1 file2′. This is useful but even then it has its risks. It is up to the user to decide, however (and after all, if a user is compromised you should assume the system is compromised because if it hasn’t been already it likely will be, so what’s the harm? Well I would disagree that there is no harm – indeed there is – but…)


THE BAD AND THE UGLY


Indeed, this is both bad and ugly. First, the bad part: confusion. Some utilities have conflicting options. So if you alias a command to use your favourite options, what if one day you want to use another option (or see if you like it) and you are used to typing the basename (so not the absolute name)? You get an error about conflicting options (or you get results you don’t expect)? Is it a bug in the program itself? Well, check aliases as well as where else the problem might occur. In  bash (for example) you can use:

$ type -P diff
/usr/bin/diff

However, is that necessarily what is executed? Let’s take a further look:

$ type -a diff
diff is aliased to `diff -N -p -u'
diff is /usr/bin/diff

So no, it isn’t necessarily the case. What happens if I use -y, which is a conflicting output type? Let’s see:

$ diff -y
diff: conflicting output style options
diff: Try 'diff --help' for more information.

Note that I didn’t even finish the command line! It detected invalid output styles and that was it. Yet it appears I did not actually specify conflicting output style types – clearly I only specified one option so this means indeed the alias was used, which means that while I specified options, those options are included and not excluding other options (certain programs will take the last option as the one that rules but not all do and diff does not here). If however, I were to do:

$ /usr/bin/diff -y
/usr/bin/diff: missing operand after '-y'
/usr/bin/diff: Try '/usr/bin/diff --help' for more information.

There we go: the error as expected. That’s how you get around it. But let’s move on to the ugly because “getting around it” is only if you remember and more so do not ever rely on aliases! Especially do not rely on it for certain commands. This cannot be overstated! The ugly is this:

It is unfortunate but Red Hat Linux based distributions have this by default and not only is it baby-sitting (which is both risky but also obnoxious much of the time … something about the two being related) it has an inherent risk. Let’s take a look at default alias for root’s  ‘rm':

# type -a rm
rm is aliased to `rm -i'
rm is /usr/bin/rm

-i means interactive. rm is of course remove. Okay so what is the big deal, surely this is helpful because as root you can wipe out the entire file system? Okay that’s fine but you can also argue the same with chown and chmod (always be careful recursively with these – well in general even – utilities… but these specifically are dangerous; they can break the system with ease). I’ll get to those in a bit. The risk is quite simple. You rely on the alias which means you never think about the risks involved; indeed, you just type ‘n’ if you don’t want to delete the files encountered (and you can send yes to all by piping ‘yes’, among other ways, if you wanted to at a one time avoid the nuisance). The risk then is, what if by chance you are an administrator (a new administrator) on another (different) system and it does not have the -i option? You then go to do something like (and one hopes you aren’t root but I’m going to show it as if I was root – in fact I’m not running this command – because it is serious):

# /usr/bin/pwd
/etc
# rm *
#

The pwd command was more of to show you a possibility. Sure, there are directories there that won’t be wiped out because there was no recursive option, but even if you are fast with sending an interrupt (usually ctrl-c but can be shown and also set with the stty command, see stty –help for more info), you are going to have lost files. The above would actually have shown that some files were directories after the rm * but before the last #, but all the files in /etc itself would be gone. And this is indeed an example of “the problem is that which is between the keyboard and chair” or “PEBKAC” (“problem exists between keyboard and chair”) or even “PICNIC” (problem in chair not in computer”), among others. Why is that? Because you relied on something one way and therefore never thought to get in the habit of being careful (and either always specifying -i or using the command in a safe manner like always making sure you know exactly what you are typing). As for chown and chmod? Well if you look at the man pages, you see the following options (for both):

--no-preserve-root
 do not treat '/' specially (the default)
--preserve-root
 fail to operate recursively on '/'

Now if you look at the man page for rm, and see these options, you’ll note a different default:

--no-preserve-root
 do not treat '/' specially
--preserve-root
 do not remove '/' (default)

The problem? You might get used to the supposed helpful behaviour with rm which would show you:

rm: it is dangerous to operate recursively on ‘/’
 rm: use --no-preserve-root to override this failsafe

So you are protected from your carelessness (you shouldn’t be careless… yes it happens and I’m guilty of it too, but this is one of the things backups were invented for, as well as only being as privileged as is necessary and only for the task in hand). But that protection is a mistake itself. This is especially true when you then look at chown and chmod, both of which are ALSO dangerous when recursively done on / (actually on many directories recursively, example to not do it on is /etc as that will break a lot of things, too). And don’t even get me started on the mistake of: chown -R luser.luser .*/ because even if you are in /home/luser/lusers, then as long as you are root (it is a risk for users to change owners and so therefore only root can do that) then you will be changing the root file system and everything under it (/etc, /bin/, /dev/, everything) to be owned by luser as the user and luser as the group. Hope you had backups. You’ll definitely need them. Oh, and yes, any recursive action on .* is a risky thing indeed. To see this in action in a safe manner, as some user, in their home directory or even a sub-directory of their home directory, try the following:

$ /usr/bin/ls -alR .*

… and you’ll notice it going to /home and then / and everything below it! The reason is the way path globbing works (try man -s 7 glob). I’d suggest you read the whole thing but the one in particular is under Pathnames.

So yes, if you rely on aliases which is relying on not thinking (which is a problem itself in so many ways) then you’re setting yourself up for a disaster. Whether that disaster in fact happens is not guaranteed but one should be prepared and not set themselves up for it in the first place. And unfortunately some distributions set you up for this by default. I’m somewhat of the mind to alias rm to ‘rm –no-preserve-root’ but I think most would consider me crazy (they’re probably more correct than they think). As for the alias rm in /root/.bashrc, here’s how you remove it (or maybe if you prefer to comment it out). Just like everything else, there’s many ways, this is at the command prompt:

# /usr/bin/sed -i 's,alias \(rm\|cp\|mv\),#alias \1,g' /root/.bashrc

Oh, by the way, yes, cp and mv (hence the command above commenting all three out) are also aliased in root’s .bashrc to use interactive mode and yes the risks are the same (you risk overwriting files when you aren’t on an aliased account and this might even be the same system that you are used to it with root but you don’t have it on all your accounts which means if you were just as root and remembered it was fine then you logout back to your normal, non-privileged user and you do some maintenance there, what happens if you then use one of those commands that is not aliased to -i? Indeed, aliases can be slightly good, bad and very ugly). Note that (although you should do this anyway) even if you were to source (by ‘source /root/.bashrc’ or equally ‘. /root/.bashrc’) the file again the aliases would still exist because it didn’t unalias them (you could of course run that too but better is log out and the next time you are logged in you won’t have that curse upon you).

One more thing that I think others should be aware of as it further proves my point about forgetting aliases (whether you have them or not). The reason I wrote this is twofold:

  • First, I’ve delayed the alias issue with rm (and similar commands) but it is something I’ve long thought of and it is indeed a serious trap.
  • Second, and this is where I really make the point: the reason this came up is one of my accounts on my server had the alias for diff as above. I don’t even remember setting it up! In fact, I don’t even know what I might have used diff for, with that account! That right there proves my point entirely (and yes, I removed it). Be aware of aliases and always be careful especially as a privileged user…

 

Open Source and Security

One of the things I often write about is how open source is in fact good for security. Some will argue the opposite to the end. But what they are relying on, at best, is security through obscurity. Just because the source code is not readily available does not mean it is not possible to find flaws or even reverse engineer it. It doesn’t mean it cannot be modified, either. I can find – as could anyone else – countless examples of this. I have personally added a feature to a Windows dll file – a rather important one, that is shell32.dll – in the past. I then went on to convince Windows file integrity check to not only see the modified file as correct but if I were to have replaced it with the original, unmodified one, then it would have replaced it with my modified version. And how did I add a feature without the source code? My point exactly. So to believe you cannot uncover how it works (or, as some will have you believe, modify and/or add features) is a huge mistake. But whatever. This is about open source and security. Before I can get in to that, however, I want to bring up something else I often write about at times.

That thing I write about is this: one should always admit to mistakes. You shouldn’t get angry and you shouldn’t take it as anything but a learning opportunity. Indeed, if you use it to better yourself, better whatever you made the mistake in (let’s say you are working on a project at work and you make a mistake that throws the project off in some way) and therefore better everything and everyone involved (or around), then you have gained and not lost. Sure, you might in some cases actually lose something (time and/or money, for example) but all good comes with bad and the reverse is true too: all bad comes with good. Put another way, I am by no means suggesting open source is perfect.

The only thing that is perfect is imperfection.
— Xexyl

I thought of that the other day. Or maybe better put, I actually got around to putting it in my fortune file (I keep a file of pending ideas for quotes as well as the fortune file itself). The idea is incredibly simple: the only thing that will consistently happen without failure is ‘failure’, time and time again. In other words, there is no perfection. ‘Failure’ because it isn’t a failure if you learn from it; it is instead successfully learning yet another thing and is another opportunity to grow. On the subject of failure or not, I want to add a more recent quote  (this was thought of earlier this month or later in August than when I originally posted this, which was 15 August) that I think really nails this idea very well:

There is no such thing as human weakness, there is only
strength and… those blinded by… the fallacy of perfection.
— Xexyl

In short, the only weakness is the product of ones’ mind. There is no perfection but if you accept this you will be much further ahead (if you don’t accept it you will be less able to take advantage of what imperfection offers). All of this together is important, though. I refer to admitting mistakes and how it is only a good thing. I also suggest that open source is by no means perfect and therefore to be critical of it, as if it is less secure, is flawed. But here’s the thing. I can think of a rather critical open source library that is used by a lot of servers, that has had a terrible year. One might think with this, and specifically what it is (which I will get to in a moment), it is somehow less secure or more problematic. What is this software? Well, let me start by noting the following CVE fixes that were pushed in to update repositories, yesterday:


 – fix CVE-2014-3505 – doublefree in DTLS packet processing
– fix CVE-2014-3506 – avoid memory exhaustion in DTLS
– fix CVE-2014-3507 – avoid memory leak in DTLS
– fix CVE-2014-3508 – fix OID handling to avoid information leak
– fix CVE-2014-3509 – fix race condition when parsing server hello
– fix CVE-2014-3510 – fix DoS in anonymous (EC)DH handling in DTLS
– fix CVE-2014-3511 – disallow protocol downgrade via fragmentation


To those who are not aware, I refer to the same software that had Heartbleed vulnerability. It therefore is also the same software as some other CVE fixes not too long after that. And indeed it seems that OpenSSL is having a bad year. Well, whatever – or perhaps better put, whomever – is the source (and yes, I truly do love puns) of the flaws, is irrelevant. What is relevant is this: they clearly are having issues. Someone or some people adding the changes are clearly not doing proper sanity checks and in general not auditing well enough. This just happens, however. It is part of life. It is a bad patch (to those that do not like puns, I am sorry, but yes, there goes another one) of time for them. They’ll get over it. Everyone does, even though it is inevitable that it happens again. As I put it: This just happens.

To those who want to be critical, and not constructively critical, I would like to remind you of the following points:

  • Many websites use OpenSSL to encrypt your data and this includes your online purchases and other credit card transactions. Maybe instead of being only negative you should think about your own mistakes more rather than attacking others? I’m not suggesting that you not considering yours, but in the case you are not, think about this. If nothing else, consider that this type of criticism will lead to nothing and since OpenSSL is critical (I am not consciously and deliberately making all these puns, it is just in my nature) then this can lead to no good and certainly is of no help.
  • No one is perfect, as I not only suggested above, but also suggested at other times. I’ll also bring it up again, in the future. Because thinking yourself infallible is going to lead to more embarrassment than if you understand this and prepare yourself, always being on the look out for mistakes and reacting appropriately.
  • Most importantly: this has nothing to do with open source versus closed source. Closed source has its issues too, including less people that can audit it. The Linux kernel, for example, and I mean the source code thereof, is on many people’s computers and that is a lot to see any issues. Issues still have and still will happen, however.

With that, I would like to end with one more thought. Apache, the organization that maintains the popular web server as well as other projects, is really to be commended for their post-attack analyses. They have a section on their website, which details attacks and the details include what mistakes they made, what happened, what they did to fix it as well as what they learned. That is impressive. I don’t know if any closed source corporations do that, but either way, it is something to really think about. It is genuine, it takes real courage to do it, and it benefits everyone. This is one example. There are immature comments there but that shows just how impressive Apache is to do this (they have other incident reports I seem to recall). The specific incident is reported here.