One of the sites we saw infected was redirecting users to a porn website after attempting to infect them with the malware. This suggests to me that they are trying to snatch as much money as they can very quickly before everyone gets back from the holidays and starts removing the injected code. They haven't been particularly quiet about this infection so I can only assume that they meant for this to infect a large number of people quickly and then be done with it.
I don't know yet what the malware does but from what we could see of it, all it does is download another piece of malware which suggests to me that the process is probably quite versatile. The second piece could be changed on the server to meet their needs or it could download further bits of malware. I have a strong suspicion that one of the functions it can perform is to continue the attacks on other websites. That would seem to be the fastest way to spread.
Based on the timing of the attack (just as everyone goes on holiday... sysadmins are at home, home users are on the web looking for the present they really wanted but didn't get this year) I'd also suspect it would be looking for credit card purchases and forwarding the numbers back to the owners of the botnet.
Neither of these two methods are particularly good at protecting you. As an analogy, imagine you are in a sword fight and every time you get hit, you place a piece of armour the same size as the gash over the gash. It would take you hours of fighting to get completely protected and you would not be protected until you had been hit everywhere.
A smarter method is to put armour on that covers everywhere and then take it off or open up holes in it as needed.
Backing away from the analogy again, use Firefox and install NoScript. When you find a site that requires JavaScript (Youtube, I'm looking at you) just add it into the allowed list.
Now, when the guys behind this attack buy a new domain name, you will already be protected.
While it is often quite difficult to get good speeds on truly rare tracks, it's also just as difficult to find those tracks in a bricks-and-mortar store.
Of course, that's not what Sony are offering here anyway. They're offering a small selection of their most popular albums and yet another crippled format. In this case, the format is the procedure: visit store and return home to download
I'm not sure the parent was intending to be funny, even though he succeeded... opening the correct ports on your firewall is actually a good idea if you want to get the maximum speed out of a torrent.
pico was what I first used on the Mac command line as well back when it really was pico and not a symlink to nano. I had been using Solaris for some time back then but I used a graphical editor in Solaris. The command line was just for shunting files around and compiling and running programs.
I first dipped my toes in the vi water when I was playing around with Linux for the first time and it didn't come with pico installed. I forget whether it had nano that I didn't know about or if it just didn't have nano. Either way, I followed the vi instructions which were difficult and complicated, finished editing my file and promptly forgot all about vi and how to do anything with it.
These days, I'm a Solaris Sysadmin and I use vi a thousand times a day. I've aliased vi to vim and set up my.vimrc file with the settings I like such as syntax highlighting. I know many of the shortcuts so I can do things more efficiently than using "x" 8 times to delete a word then "i" to type a new one. I can use "cw" which will change to the end of the word and just start typing the new one. I know how to do search and replace using regular expressions, across the whole file or just a subset of the file. If I'm writing code I can fold a function down so that it appears to be just the declaration which allows me to see the function above and below on the same screen. I know how to block-comment and uncomment code with a single command.
A new developer recently asked the sysadmins if we could install pico for him and we said "Yes... but you'd be doing yourself a favour if you learned vi instead." I pointed him at a vi tutorial and I gave him a printout of the vi reference that I have stashed away somewhere.
Once you know how to use vi and I mean USE vi, not just emulate pico within vi, then you'll find every other editor sorely lacking.
One thing I love about Unix (and this is true about Linux as well) is that any program is just a few keystrokes away rather than having to navigate through submenu after submenu to find the program you want.
The best feature, however, is that you can effortlessly chain the output of one program into the input of another. The number of times I grep through a log file, pipe the output to cut, then to sort, then to uniq each day makes that functionality indespensible. I was trying to create a list of all the URLs that one of our web pages contained the other day using TextPad (a Windows text editor) and I eventually succeeded but it took me several minutes of searching and replacing using regular expressions. I achieved the same task in under thirty seconds using curl piped to grep piped to sed. The best thing was that with the curl-grep-sed combination, all I had to do was change the URL of the page I was dealing with at the start of the command and the whole process would work instantly for the next page as well. The TextPad method would have taken another five minutes for every page I worked on.
My personal favourite (Would be No. 1 on my list):
1. Read the error message you are presented with and do what it says to do.
So often I get people ringing up with an error who expect me to fix it even when the instructions on how to fix it are right there on their screen in front of them. They usually don't send me the error message or even read it to me when it occurs on their screen, they just click OK or Cancel or whatever makes it go away. I walk down to their desk, read the instructions and do what they say to do.
The ultimate example of this happened recently: a couple of emails reached me that had originally been the weekly mail-out from one of our websites. The customer forwarded it one of the editors asking him to unsubscribe her. He forwarded it to IT who forwarded it to someone in Ops (They handle HTML, CSS and other stuff too complicated for editors) who forwarded it to someone else in Ops more relevant who eventually forwarded it to me, the sysadmin. I clicked the unsubscribe link that was still contained in the bottom of the customer's original email.
I'll also throw in a number 2:
2. Give me plenty of notice of requests you know about in advance.
If I have told you in the past that this kind of job takes three days, CCing your request to the CEO won't make it happen any faster. It's not that your job is at the end of the queue and it will take me three days to get to it, it's just that this job takes me three days to complete.
Strangely enough, the anonymity and the remote file inclusion are not the only issues here. I recently discovered Yahoo's Slurp running these sorts of queries (they were parameters to a search page) on several different sites that we host. The "attacker" had realised that we use the same code across several sites and could use exactly the same "exploit".
The interesting part was that the goal of the "attacker" was not to run an exploit against our machines but to attempt to inject a link into the page that Yahoo would then index and would increase the pagerank of the target of the link. The targets of the links all seemed to be Google Adsense spam pages. The "attacker" was basically using our reasonably good pagerank to increase his.
The easiest solution we found was to disallow spiders from crawling search results pages as they should be able to find all of our pages by following links on the site and shouldn't need to use the search. There's probably a down side to this approach but it seems to work so far.
I'm not sure of the laws concerning this in the US but don't publicly funded websites have to comply with section 508 ?
A gentle reminder from a few blind citizens should be enough to convince them to put the data back up in text form and hopefully do something serious about terrorism, like consulting an expert instead of just making shit up.
The false positive rate is too high already with the current lot of image-based captchas and it's only going to get worse as captcha recognition software gets better and requires that the captchas are harder to "see". The number of legitimate users who are turned away is not trivial either. Captchas don't work very well for people with poor eye-sight and the tiny little picture of a speaker or a wheelchair next to the image that is supposed to represent the audio version of the captcha isn't much use to those people either because they can't see it either. Most forum software requires that you have some form of image manipulation library on your server to generate these images which seems fairly unnessecary anyway. How many forum maintainers actually use gd or ImageMagick other than for captcha generation ?
Language recognition: Software isn't very good at discerning the meaning of a sentence. Ask a simple, self-contained question that a human will find trivial to answer. eg. "What is the second last word in this sentence ?". or "If I have one white horse and one brown horse, how many horses do I have ?". This, however, may not solve the parent's problem of stopping sweatshop captcha breaking.
Alternate Language: The way the above method WILL solve the sweatshop problem is through the people in the sweatshop not knowing the language you are using. I suspect that the people involved don't even know what board they are posting to. They just get an image, a text box and a submit button. They don't know English and they almsot certainly don't know Japanese. If your board is in a language that they don't understand then replacing image-based captchas with language-based ones will solve the problem. (Temporarily. See below for why...)
Combination image/language: Ask the user to do something different with the captcha. Sometimes they are asked for it as per normal, sometimes backwards, sometimes only the even-index letters, sometimes you could ask for the odd numbers or only the numbers in a mixed numbers-letters image. Even if you only had a small number of variations that you could ask for, this would significantly reduce the number of successful captcha breaking attempts. Alternatively, it could increase the complexity of the captcha breaking software/sweatshop labourers. It's hard to get people with logic and reasoning skills for $.60/hour.
Cultural: The cultural idea mentioned in the parent is fraught with danger. I suspect that there will be a high false positive rate because the test is not self contained. It relies on the user having some knowledge and not all legitimate users will have that knowledge.
Lastly, the spammer's methods will likely evolve to meet whatever captchas we can dream up. It wouldn't be hard to devise a phishing scheme, ad-ware program or even an XSS attack that tricks a legitimate user into passing the captcha and then hijacking that and using the account for spam. This method wouldn't even cost $.60/hour. It would probably be almost free and it would have a higher success rate than their current methods. It would just involve some sort of high volume email-spamming for the phishing, normal spyware installation methods or breaking into many bulletin boards to effect the XSS attack. I suspect that these methods will start to seem more attractive to spammers when captchas get harder.
That said, it's an arms race and you only lose when you give up. Bring on the next round of better captchas !
We're starting to get quite off-topic here but it needs addressing.
The reasons for reading the entire article vary from person to person.
If you are a slashdot editor the it's your job to read the entire article. If you're an iTunes user then it may be in your best interests to read past the first page. If you are a record company exec then your future job may depend on it. If, like me, you realise that the author intended the whole article to be read in one go and, as most authors do, put the most salient points at the end (the conclusion) of the article then you'll press on even if the writing style is bad to get to the point of the article.
People who have novel and interesting ideas are not necessarily good writers and good writers often have no novel and interesting ideas. In fact, good writers often take a bad article that contains good ideas, rewrite it in their own words and make an absolute mint out of it. That's not to say you can't find both qualities in one person, just that such a combination is exceedingly rare.
I've made this point about University lecturers before. Every single one of my lecturers at University were very smart people but only two or three of them made good lecturers. Most of them were simply going through the motions of teaching a subject they didn't care about so they could get the funding to do the research they did care about. Corner one of them and bring up a topic they did care about and you could learn volumes of information from them but sitting through lectures where the stooge out the front reads the text book to you is a waste of time.
The job of an editor of a news aggregation site is to find the articles that have ineteresting views and summarise the view in such a way that you are given enough information to decide whether you want to read the full article or not but there is still a point to reading the full article if you decide to. After this, the quality of the ideas in the article is what matters and not so much the quality of the writing.
Finally. Someone who read ALL THREE pages of the article. The point of the article was not that Apple's DRM is bad. (Like the Slashdot headline says.) The points of the article were:
DRM is bad. Apple's DRM isn't as bad for consumers as other DRMs are. Apple's DRM is worse for record companies than other DRMs are. Apple's DRM effectively locks users in to iPods. Most other DRMs are just there to get the record companies to hand over the content. iPods are so popular now that record companies can't play hard ball with Apple any more. Apple became the most popular by providing a better service, not because of their DRM. The only way other providers can get their music onto iPods is to remove DRM. The only way other comapnies can compete with iTunes is to provide a better service.
Most comments here seem to indicate that the Slashdotter only read the first page of the article; the bit about DRM being bad and how Apple's DRM is easily circumvented. We already know that stuff... it's been on Slashdot for years. The insight only comes on the third page where Doctorow suggests that the only way forward is to forget DRM altogether.
I suspect that point is aimed at record company execs and not at Slashdot punters. I particularly like the way he connected the failure of DRM (to be useful to consumers) in DVDs to Blueray and DVD-HD in an article about DRM on music sold at iTunes.
He's really asking record company execs to connect the dots; if you want to be as successful as iTunes/iPod then you need to forget DRM.
I'm right there with you on this one. In my casual comparison of the two services, the accessible search turned up mostly the same results as the normal search but without the domain parking and other less relevant sites.
The accessible version tended to show up more.org results than the normal version but I suspect this is a correlation between people who understand the difference between.org and.com and people who understand the importance of accessible web design.
I'll be using the comparison site for a while but if the accessible version continues to produce more relevant results (and nicer pages with css and stuff...) then I think I'll switch for good.
The primary difference would be that if a builder, electrician or gas installer screw up, people's lives are in jeopardy. I'd go as far as to say that people's lives are likely to be lost. If a coder screws up, people's details and company secrets are likely to be lost (well, they still have the details and secrets but so do the bad guys) but no one's lives are lost.
A qualification is not a bad thing, in fact, a goverment recognised qualification could certainly aid businesses in finding suitable security coders and qualified security coders in finding employment, but mandating it is just a bit over the top.
The question is: how do you verify the integrity of a program before running it on your system ?
You could read through the source code... no, that's ridiculous. Unless the program is as simple as this one was (I think I could re-write this in one line of awk) then reading the source code would take weeks or even months. That's assuming you have the knowledge.
You could take the recommendation of a trusted source; a source who is trusted through having recommended other software before which was good software and not malicious or buggy. Unfortunately, that is what happened here. TUAW (a trusted source) recommended some software without actually using it themselves. (Unless it was some giant prank on their userbase but that sort of thing is usually reserved for early April.)
You could limit yourself to only using software that came in a box from your local Apple store. Don't ever install anything unless you also have a physical, printed CD, a box, a user manual and a warranty to accompany it. That's a bit extreme but reasonably safe. As with all "reasonably safe" things however, it's pretty boring.
What most people do these days is decide if the software "looks trustworthy". This is usually based on a recommendation from a trsuted source, the product's website (professional looking graphics means money spent, which means legit) and if the product still isn't filling the user with confidence they will usually ask Google. All that needs to be done to install malicious software on a user's computer is to create a moderately professional looking website, astroturf a few software-related forums and get your software linked from a trsuted source. The best way to that would be to name your software in such a way that tech-savvy people would probably not install the program but the less savvy would jump at it.
I'd like to hear comments anyone has on how unknown software can be verified by non techie people. This means no md5 hashes, no source code snooping, nothing even remotely technical like checking the size of the program. I know the odds are that the 20KB "Open Source MS Office Replacement" I just downloaded probably isn't what it claims to be but plenty of users don't even look at the size of a download.
You don't have to sign up or anything, just find the "Intro to programming" class, find a seat and listen. Do the assignments (you'll know if they're right because they'll compile and do what is asked. It might also be worthwhile finding a guru friend that can help you out. These can be found in Linux user groups and in the tech labs at the University) In a lecture full of 400 or so people they don't check the roll and kick you out just because you haven't paid. You won't get a degree at the end of it all but you'll have the knowledge and that will make the degree a walk in the park if you decide to go back and do it.
If there's a choice between a procedural language and an object-oriented language, go for the object oriented one first. If there are follow-up courses in second year, take them too. Lots of the courses in second year such as "Data security", "Networking", "Operating systems" and "Machine Intelligence" rely on you knowing the language you learned in first year and extending your knowledge.
There will probably be a web-based subject or two; one where you learn HTML and Javascript (and maybe css), the other where you learn server-side scripting such as JSP, PHP or Perl (or one of many other languages.) These are great as an intro to the language but I would suggest while you are doing these courses getting an old machine to act as a server and learning the admin side of the web technologies. Set up a web server with server side scripting and a database and create a website. Write howto guides. I did that while I was at University and I found that the process of writing the guide helped me to understand the language far better than I did before. If they're good enough (and appropriate) submit them to tldp.org or just host them yourself. You can help someone else get through this easier than you had it.
There will also be some courses on the "Fundamentals of Computer Science" and "Algorithmics". These teach the concepts that will change you from an amateur hacker into a quality programmer. These subjects often involve little or no programming at all but what you learn is about how languages in general work and how a different algorithm can turn the fastest computer into a slug and another can breathe life back into a 486. I have personally written two programs that solve the same problem. One, a 486 could run through in an hour, the other would take more than 200,000 years on the Earth Simulator. (I don't think they'd let me run it.)
Most of all, as someone has said previously, do stuff. The more programming you do, the better you will get at it. The more languages you learn, the easier the next one will be. The more you tinker with your operating system, the fewer mistakes you will make. The more operating systems you use, the more employable you will be.
Some further thoughts on this: Imagine a situation where three load balanced web servers with internet-facing interfaces and a database server which has no internet-facing interface. A compromise of one of the web servers would allow (with a captured user-agent) a compromise of the database server.
Obviously the statement from my last post is not entirely accurate.
This also highlights the need for an intrusion detection system on a seperate machine that is not able to be compromised (ie. does not accept connections from anywhere) and can warn you that machine x has been compromised and not to ssh to it as doing so may enable a compromise of further machines.
After your description of the exploit attempt I had another, very careful read of the author's description and have come to the conclusion that we were both wrong. He is suggesting that other DMZ hosts would be compromised using the authentication credentials that should be safely behind the firewall. No internal boxes would be compromised.
From the article: (emphasis mine)
What are the chances that the administrator has configured access to all the DMZ servers he controls? Altering some environment variables allows the intruder to attempt to access other DMZ hosts with our administrator's private key. This can mean direct access as root or local administrator. And so this socket file becomes a door to many other systems in the DMZ.
The convoluted setup using the workstation and the patching server were irrelevant to the fact that there was an ssh-key connection to a compromised box which then used agent-forwarding to connect to and compromise other boxes in the DMZ.
As long as the DMZ is properly firewalled from the internal boxes it should be impossible to actively compromise them using a forwarded ssh key and hence you were completely correct in stating that your description of the attack was impossible. (I hope. If it were possible that would be... bad.
This would also mean that if the administrator had a different public-key/private-key pair for each box in the DMZ then the attacker could not agent-forward the ssh session to other boxes and would have to compromise each one manually. However, since most boxes in a DMZ are often configured identically with a load balancer in front of them, a flaw on one that allowed the inital compromise would likely be replicated to all the others and allow them to be compromised in the same way.
He also goes on to suggest that there might be a flaw in the administrator's patch loading scripts that allows execution of code on the patch-server but that is an entirely seperate issue and not concerned with ssh at all.
Not quite. If you have broken into the DMZ, that's all you have. Even mildly competent sysadmins know not to trust the DMZ and therefore you do not automatically have access to the rest of the network, nor do you have access to any confidential documents.
The exploit mentioned in the article doesn't rely on ssh being configured to connect directly to root. It relies on the attacker having gained root access on the box being ssh'd to by the sysadmin. Once the sysadmin has ssh'd to the comnpromised box (as any user) the attacker can then ssh to any other box the sysadmin has configured to use agent forwarding.
Two solutions to prevent this compromise of the rest of the network: 1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.
2) Use a different public/private key pair for each box. That way, if you didn't firewall the DMZ off it would still fail on the key authentication. The drawback of this is a) the attacker can still ssh to your admin box which contains all of the private keys and b) you lose most of the advantage of agent forwarding; the ability to ssh through a chain of boxes without any but the first needing to store the private key.
I suppose the underlying message in the article is "You REALLY can't trust anything in a DMZ that may have been compromised. ssh is a tool that can be turned against you if one of your machines is compromised."
It's not just you. I had to re-read it several times.
I think the main point (the one the article submitter picked up on) was that if an attacker can compromise your DMZ box (the most vulnerable box your company owns and hence the least trusted box your company owns) that has no private ssh keys stored on it and can't connect to any other trusted box but does have trusted boxes connecting to it, then he can use that to compromise further trusted boxes inside the organisation.
To put it another way, if you ssh to an attacker's machine using agent forwarding he can probably ssh back to yours.
Maybe complacent was the wrong word; I was tired and not thinking correctly.
The question is now: how do you know that you haven't passed on a virus. Some are really obvious (Netsky comes to mind) when you receive them in an email but some (like thus.gen) aren't pretending to be from someone in a friend's address book; they are actually a legitemate email from a friend with a legitemate Word attachment that just happens to also contain a Macro virus.
If you forward it... you have passed on the infection. If you open it, you will have infected every Word document you open after that until you remove the infection (several ways to do that including deleting every infected Word file and re-installing Word but running a virus checker would also work) which means that any Word file you email would be infected.
Can you honestly say that you have never received a Word file in your email and either forwarded it on or opened it ? Never ? If so, well done but Word is only one example of a vector for executing cross-platform code.
The good news is that Macs don't suffer the symptoms because they don't allow MS Word the kind of access that the virus needs to the file system to do it's damage. (and also because I suspect that the virus exploits an error in the Windows version to run code in memory and not just interpreted macro code.)
Mistakes are inevitable but denying they exist, languishing before fixing them and claiming to have a "new focus on security" while continuing to produce bug and exploit ridden code is inexcusable. Unfortunately, the best I can do to punish them is to suggest to everyone that asks that they avoid these bug ridden products and use something more secure.
Don't forget that while you may not suffer from the symptoms of a virus you can still be a carrier.
I used work at a Mac-centric organisation that received a.doc file infected with thus.gen. It was a macro virus and hence the macro part of it worked just fine on the Mac version of MS Office and infected the normal.dot file and therefore every file opened after the initial infection. It got to the point where something like 50% of the Word files in the organisation were infected and nobody knew... then we sent one to a goverment department who were all Windows-based and their virus scanner blocked it. After that, there was a mad rush to update the virus scanner on our mail server (hadn't been touched in three years) and provide tools for the users to remove the virus (I think it just stripped all macros from the Word docs but very few people in that organisation used macros anyway.)
Even other kinds of viruses can be re-transmitted by Mac users.
Feel free to enjoy your safety and complacency and keep evangelising Macs as much as you like but don't forget that you can inadvertantly pass on infections that you receive and damage other people's computers. Viruses are not a threat you can ignore just because you own a Mac.
I don't know about you but I don't find this funny anymore. It might have something to do with only one of the points actually being valid with respect to this article and even that one's only a "maybe".
In case you hadn't noticed, the government isn't actually advocating any particular approach but simply saying that you must take some approach to fighting spam or we'll fine you big time.
All this code has really done is to create a big stick that the government can use to whack ISPs who harbour spammers or who make it easy for spammers to operate. I'm sure this will improve the situation somewhat but three quarters of Australian ISPs will already comply with this code today, before it is enforced and the others are probably the small players. The market place demands that ISPs have spam filtering and virus scanning. Not sending out devices in default configuration is just common sense. Common sense is now legally mandated.
I suspect the point of the article was that it can now be done in realtime. The journalist may not have picked up that plotting traffic patterns was old hat but I'm sure the MIT researchers knew. Realtime traffic patterns would have many more uses than daily plots of the traffic patterns particularly in responding to emergencies.
The article uses the words "regular intervals" which doesn't really give us much idea of how often this is but "realtime" suggests that it's somewhere in the realm of every minute or several times a minute.
I like to think that researchers at MIT working on something that journalists report as "cutting edge" probably is cutting edge, however it may not be that the aspect of it the gets all the emphasis is actually the cutting edge part.
While that episode was funny, I have to disagree with the general sentiment of your post. I expect my scientists to be experts in their fields and I expect my journalists to be experts in the English language and writing styles. (English because I don't speak anything else... not because I expect everyone's journalists to write in English.)
Journalists should have to study enough from books and interviewing the scientists to write an accurate and informative article. Without their scientific books, they are just another English major but with them they are able to distil the information into a form that the masses can understand.
A teacher who is dependent on books can still be a good teacher as long as they still have their books. But someone who is not a good teacher will not be a good teacher even with their books.
There are two aspects; the knowledge and the skill (of writing for journalists or teaching for teachers). Without the skill, you have nothing but without the knowledge you can always look it up in books.
There are many other valid points raised in other posts but this post is purely about whether journalists should have to have a high level of knowledge of their subject for each and every article they write or whether they should be able to learn just enough to cover the article and then promptly forget it all in time for the next article on a different topic. It would probably be a good idea for the journalists to submit the article back to the scientists who are doing the research (or at least a scientist in a relevant field) for accuracy checking before publishing.
Slashdot Mirror
If you read the article carefully you will see that he is actually recommending anti virus for most users.
His argument boils down to this: if you don't ever do anything that could infect you with a virus then you don't need a virus scanner.
This is true on Windows, Mac or Linux.
One of the sites we saw infected was redirecting users to a porn website after attempting to infect them with the malware. This suggests to me that they are trying to snatch as much money as they can very quickly before everyone gets back from the holidays and starts removing the injected code. They haven't been particularly quiet about this infection so I can only assume that they meant for this to infect a large number of people quickly and then be done with it.
I don't know yet what the malware does but from what we could see of it, all it does is download another piece of malware which suggests to me that the process is probably quite versatile. The second piece could be changed on the server to meet their needs or it could download further bits of malware. I have a strong suspicion that one of the functions it can perform is to continue the attacks on other websites. That would seem to be the fastest way to spread.
Based on the timing of the attack (just as everyone goes on holiday... sysadmins are at home, home users are on the web looking for the present they really wanted but didn't get this year) I'd also suspect it would be looking for credit card purchases and forwarding the numbers back to the owners of the botnet.
Neither of these two methods are particularly good at protecting you. As an analogy, imagine you are in a sword fight and every time you get hit, you place a piece of armour the same size as the gash over the gash. It would take you hours of fighting to get completely protected and you would not be protected until you had been hit everywhere.
A smarter method is to put armour on that covers everywhere and then take it off or open up holes in it as needed.
Backing away from the analogy again, use Firefox and install NoScript. When you find a site that requires JavaScript (Youtube, I'm looking at you) just add it into the allowed list.
Now, when the guys behind this attack buy a new domain name, you will already be protected.
While it is often quite difficult to get good speeds on truly rare tracks, it's also just as difficult to find those tracks in a bricks-and-mortar store.
Of course, that's not what Sony are offering here anyway. They're offering a small selection of their most popular albums and yet another crippled format. In this case, the format is the procedure: visit store and return home to download
I'm not sure the parent was intending to be funny, even though he succeeded... opening the correct ports on your firewall is actually a good idea if you want to get the maximum speed out of a torrent.
pico was what I first used on the Mac command line as well back when it really was pico and not a symlink to nano. I had been using Solaris for some time back then but I used a graphical editor in Solaris. The command line was just for shunting files around and compiling and running programs.
.vimrc file with the settings I like such as syntax highlighting. I know many of the shortcuts so I can do things more efficiently than using "x" 8 times to delete a word then "i" to type a new one. I can use "cw" which will change to the end of the word and just start typing the new one. I know how to do search and replace using regular expressions, across the whole file or just a subset of the file. If I'm writing code I can fold a function down so that it appears to be just the declaration which allows me to see the function above and below on the same screen. I know how to block-comment and uncomment code with a single command.
I first dipped my toes in the vi water when I was playing around with Linux for the first time and it didn't come with pico installed. I forget whether it had nano that I didn't know about or if it just didn't have nano. Either way, I followed the vi instructions which were difficult and complicated, finished editing my file and promptly forgot all about vi and how to do anything with it.
These days, I'm a Solaris Sysadmin and I use vi a thousand times a day. I've aliased vi to vim and set up my
A new developer recently asked the sysadmins if we could install pico for him and we said "Yes... but you'd be doing yourself a favour if you learned vi instead." I pointed him at a vi tutorial and I gave him a printout of the vi reference that I have stashed away somewhere.
Once you know how to use vi and I mean USE vi, not just emulate pico within vi, then you'll find every other editor sorely lacking.
One thing I love about Unix (and this is true about Linux as well) is that any program is just a few keystrokes away rather than having to navigate through submenu after submenu to find the program you want.
The best feature, however, is that you can effortlessly chain the output of one program into the input of another. The number of times I grep through a log file, pipe the output to cut, then to sort, then to uniq each day makes that functionality indespensible.
I was trying to create a list of all the URLs that one of our web pages contained the other day using TextPad (a Windows text editor) and I eventually succeeded but it took me several minutes of searching and replacing using regular expressions. I achieved the same task in under thirty seconds using curl piped to grep piped to sed. The best thing was that with the curl-grep-sed combination, all I had to do was change the URL of the page I was dealing with at the start of the command and the whole process would work instantly for the next page as well. The TextPad method would have taken another five minutes for every page I worked on.
My personal favourite (Would be No. 1 on my list):
1. Read the error message you are presented with and do what it says to do.
So often I get people ringing up with an error who expect me to fix it even when the instructions on how to fix it are right there on their screen in front of them. They usually don't send me the error message or even read it to me when it occurs on their screen, they just click OK or Cancel or whatever makes it go away. I walk down to their desk, read the instructions and do what they say to do.
The ultimate example of this happened recently: a couple of emails reached me that had originally been the weekly mail-out from one of our websites. The customer forwarded it one of the editors asking him to unsubscribe her. He forwarded it to IT who forwarded it to someone in Ops (They handle HTML, CSS and other stuff too complicated for editors) who forwarded it to someone else in Ops more relevant who eventually forwarded it to me, the sysadmin. I clicked the unsubscribe link that was still contained in the bottom of the customer's original email.
I'll also throw in a number 2:
2. Give me plenty of notice of requests you know about in advance.
If I have told you in the past that this kind of job takes three days, CCing your request to the CEO won't make it happen any faster. It's not that your job is at the end of the queue and it will take me three days to get to it, it's just that this job takes me three days to complete.
Strangely enough, the anonymity and the remote file inclusion are not the only issues here. I recently discovered Yahoo's Slurp running these sorts of queries (they were parameters to a search page) on several different sites that we host. The "attacker" had realised that we use the same code across several sites and could use exactly the same "exploit".
The interesting part was that the goal of the "attacker" was not to run an exploit against our machines but to attempt to inject a link into the page that Yahoo would then index and would increase the pagerank of the target of the link. The targets of the links all seemed to be Google Adsense spam pages. The "attacker" was basically using our reasonably good pagerank to increase his.
The easiest solution we found was to disallow spiders from crawling search results pages as they should be able to find all of our pages by following links on the site and shouldn't need to use the search. There's probably a down side to this approach but it seems to work so far.
I'm not sure of the laws concerning this in the US but don't publicly funded websites have to comply with section 508 ?
A gentle reminder from a few blind citizens should be enough to convince them to put the data back up in text form and hopefully do something serious about terrorism, like consulting an expert instead of just making shit up.
Captchas need an overhaul anyway.
The false positive rate is too high already with the current lot of image-based captchas and it's only going to get worse as captcha recognition software gets better and requires that the captchas are harder to "see". The number of legitimate users who are turned away is not trivial either. Captchas don't work very well for people with poor eye-sight and the tiny little picture of a speaker or a wheelchair next to the image that is supposed to represent the audio version of the captcha isn't much use to those people either because they can't see it either.
Most forum software requires that you have some form of image manipulation library on your server to generate these images which seems fairly unnessecary anyway. How many forum maintainers actually use gd or ImageMagick other than for captcha generation ?
Language recognition:
Software isn't very good at discerning the meaning of a sentence. Ask a simple, self-contained question that a human will find trivial to answer. eg. "What is the second last word in this sentence ?". or "If I have one white horse and one brown horse, how many horses do I have ?". This, however, may not solve the parent's problem of stopping sweatshop captcha breaking.
Alternate Language:
The way the above method WILL solve the sweatshop problem is through the people in the sweatshop not knowing the language you are using. I suspect that the people involved don't even know what board they are posting to. They just get an image, a text box and a submit button. They don't know English and they almsot certainly don't know Japanese. If your board is in a language that they don't understand then replacing image-based captchas with language-based ones will solve the problem. (Temporarily. See below for why...)
Combination image/language:
Ask the user to do something different with the captcha. Sometimes they are asked for it as per normal, sometimes backwards, sometimes only the even-index letters, sometimes you could ask for the odd numbers or only the numbers in a mixed numbers-letters image. Even if you only had a small number of variations that you could ask for, this would significantly reduce the number of successful captcha breaking attempts. Alternatively, it could increase the complexity of the captcha breaking software/sweatshop labourers. It's hard to get people with logic and reasoning skills for $.60/hour.
Cultural:
The cultural idea mentioned in the parent is fraught with danger. I suspect that there will be a high false positive rate because the test is not self contained. It relies on the user having some knowledge and not all legitimate users will have that knowledge.
Lastly, the spammer's methods will likely evolve to meet whatever captchas we can dream up. It wouldn't be hard to devise a phishing scheme, ad-ware program or even an XSS attack that tricks a legitimate user into passing the captcha and then hijacking that and using the account for spam. This method wouldn't even cost $.60/hour. It would probably be almost free and it would have a higher success rate than their current methods. It would just involve some sort of high volume email-spamming for the phishing, normal spyware installation methods or breaking into many bulletin boards to effect the XSS attack.
I suspect that these methods will start to seem more attractive to spammers when captchas get harder.
That said, it's an arms race and you only lose when you give up. Bring on the next round of better captchas !
We're starting to get quite off-topic here but it needs addressing.
The reasons for reading the entire article vary from person to person.
If you are a slashdot editor the it's your job to read the entire article.
If you're an iTunes user then it may be in your best interests to read past the first page.
If you are a record company exec then your future job may depend on it.
If, like me, you realise that the author intended the whole article to be read in one go and, as most authors do, put the most salient points at the end (the conclusion) of the article then you'll press on even if the writing style is bad to get to the point of the article.
People who have novel and interesting ideas are not necessarily good writers and good writers often have no novel and interesting ideas. In fact, good writers often take a bad article that contains good ideas, rewrite it in their own words and make an absolute mint out of it. That's not to say you can't find both qualities in one person, just that such a combination is exceedingly rare.
I've made this point about University lecturers before. Every single one of my lecturers at University were very smart people but only two or three of them made good lecturers. Most of them were simply going through the motions of teaching a subject they didn't care about so they could get the funding to do the research they did care about. Corner one of them and bring up a topic they did care about and you could learn volumes of information from them but sitting through lectures where the stooge out the front reads the text book to you is a waste of time.
The job of an editor of a news aggregation site is to find the articles that have ineteresting views and summarise the view in such a way that you are given enough information to decide whether you want to read the full article or not but there is still a point to reading the full article if you decide to.
After this, the quality of the ideas in the article is what matters and not so much the quality of the writing.
Finally. Someone who read ALL THREE pages of the article.
The point of the article was not that Apple's DRM is bad. (Like the Slashdot headline says.)
The points of the article were:
DRM is bad.
Apple's DRM isn't as bad for consumers as other DRMs are.
Apple's DRM is worse for record companies than other DRMs are.
Apple's DRM effectively locks users in to iPods.
Most other DRMs are just there to get the record companies to hand over the content.
iPods are so popular now that record companies can't play hard ball with Apple any more.
Apple became the most popular by providing a better service, not because of their DRM.
The only way other providers can get their music onto iPods is to remove DRM.
The only way other comapnies can compete with iTunes is to provide a better service.
Most comments here seem to indicate that the Slashdotter only read the first page of the article; the bit about DRM being bad and how Apple's DRM is easily circumvented. We already know that stuff... it's been on Slashdot for years. The insight only comes on the third page where Doctorow suggests that the only way forward is to forget DRM altogether.
I suspect that point is aimed at record company execs and not at Slashdot punters. I particularly like the way he connected the failure of DRM (to be useful to consumers) in DVDs to Blueray and DVD-HD in an article about DRM on music sold at iTunes.
He's really asking record company execs to connect the dots; if you want to be as successful as iTunes/iPod then you need to forget DRM.
I'm right there with you on this one. In my casual comparison of the two services, the accessible search turned up mostly the same results as the normal search but without the domain parking and other less relevant sites.
.org results than the normal version but I suspect this is a correlation between people who understand the difference between .org and .com and people who understand the importance of accessible web design.
The accessible version tended to show up more
I'll be using the comparison site for a while but if the accessible version continues to produce more relevant results (and nicer pages with css and stuff...) then I think I'll switch for good.
The primary difference would be that if a builder, electrician or gas installer screw up, people's lives are in jeopardy. I'd go as far as to say that people's lives are likely to be lost. If a coder screws up, people's details and company secrets are likely to be lost (well, they still have the details and secrets but so do the bad guys) but no one's lives are lost.
A qualification is not a bad thing, in fact, a goverment recognised qualification could certainly aid businesses in finding suitable security coders and qualified security coders in finding employment, but mandating it is just a bit over the top.
The question is: how do you verify the integrity of a program before running it on your system ?
You could read through the source code... no, that's ridiculous. Unless the program is as simple as this one was (I think I could re-write this in one line of awk) then reading the source code would take weeks or even months. That's assuming you have the knowledge.
You could take the recommendation of a trusted source; a source who is trusted through having recommended other software before which was good software and not malicious or buggy. Unfortunately, that is what happened here. TUAW (a trusted source) recommended some software without actually using it themselves. (Unless it was some giant prank on their userbase but that sort of thing is usually reserved for early April.)
You could limit yourself to only using software that came in a box from your local Apple store. Don't ever install anything unless you also have a physical, printed CD, a box, a user manual and a warranty to accompany it. That's a bit extreme but reasonably safe. As with all "reasonably safe" things however, it's pretty boring.
What most people do these days is decide if the software "looks trustworthy". This is usually based on a recommendation from a trsuted source, the product's website (professional looking graphics means money spent, which means legit) and if the product still isn't filling the user with confidence they will usually ask Google.
All that needs to be done to install malicious software on a user's computer is to create a moderately professional looking website, astroturf a few software-related forums and get your software linked from a trsuted source. The best way to that would be to name your software in such a way that tech-savvy people would probably not install the program but the less savvy would jump at it.
I'd like to hear comments anyone has on how unknown software can be verified by non techie people. This means no md5 hashes, no source code snooping, nothing even remotely technical like checking the size of the program. I know the odds are that the 20KB "Open Source MS Office Replacement" I just downloaded probably isn't what it claims to be but plenty of users don't even look at the size of a download.
Seriously, GO.
You don't have to sign up or anything, just find the "Intro to programming" class, find a seat and listen. Do the assignments (you'll know if they're right because they'll compile and do what is asked. It might also be worthwhile finding a guru friend that can help you out. These can be found in Linux user groups and in the tech labs at the University)
In a lecture full of 400 or so people they don't check the roll and kick you out just because you haven't paid. You won't get a degree at the end of it all but you'll have the knowledge and that will make the degree a walk in the park if you decide to go back and do it.
If there's a choice between a procedural language and an object-oriented language, go for the object oriented one first. If there are follow-up courses in second year, take them too. Lots of the courses in second year such as "Data security", "Networking", "Operating systems" and "Machine Intelligence" rely on you knowing the language you learned in first year and extending your knowledge.
There will probably be a web-based subject or two; one where you learn HTML and Javascript (and maybe css), the other where you learn server-side scripting such as JSP, PHP or Perl (or one of many other languages.) These are great as an intro to the language but I would suggest while you are doing these courses getting an old machine to act as a server and learning the admin side of the web technologies. Set up a web server with server side scripting and a database and create a website. Write howto guides. I did that while I was at University and I found that the process of writing the guide helped me to understand the language far better than I did before. If they're good enough (and appropriate) submit them to tldp.org or just host them yourself. You can help someone else get through this easier than you had it.
There will also be some courses on the "Fundamentals of Computer Science" and "Algorithmics". These teach the concepts that will change you from an amateur hacker into a quality programmer. These subjects often involve little or no programming at all but what you learn is about how languages in general work and how a different algorithm can turn the fastest computer into a slug and another can breathe life back into a 486. I have personally written two programs that solve the same problem. One, a 486 could run through in an hour, the other would take more than 200,000 years on the Earth Simulator. (I don't think they'd let me run it.)
Most of all, as someone has said previously, do stuff. The more programming you do, the better you will get at it. The more languages you learn, the easier the next one will be. The more you tinker with your operating system, the fewer mistakes you will make. The more operating systems you use, the more employable you will be.
Some further thoughts on this:
Imagine a situation where three load balanced web servers with internet-facing interfaces and a database server which has no internet-facing interface. A compromise of one of the web servers would allow (with a captured user-agent) a compromise of the database server.
Obviously the statement from my last post is not entirely accurate.
This also highlights the need for an intrusion detection system on a seperate machine that is not able to be compromised (ie. does not accept connections from anywhere) and can warn you that machine x has been compromised and not to ssh to it as doing so may enable a compromise of further machines.
From the article: (emphasis mine)
The convoluted setup using the workstation and the patching server were irrelevant to the fact that there was an ssh-key connection to a compromised box which then used agent-forwarding to connect to and compromise other boxes in the DMZ.
As long as the DMZ is properly firewalled from the internal boxes it should be impossible to actively compromise them using a forwarded ssh key and hence you were completely correct in stating that your description of the attack was impossible. (I hope. If it were possible that would be... bad.
This would also mean that if the administrator had a different public-key/private-key pair for each box in the DMZ then the attacker could not agent-forward the ssh session to other boxes and would have to compromise each one manually. However, since most boxes in a DMZ are often configured identically with a load balancer in front of them, a flaw on one that allowed the inital compromise would likely be replicated to all the others and allow them to be compromised in the same way.
He also goes on to suggest that there might be a flaw in the administrator's patch loading scripts that allows execution of code on the patch-server but that is an entirely seperate issue and not concerned with ssh at all.
Not quite. If you have broken into the DMZ, that's all you have. Even mildly competent sysadmins know not to trust the DMZ and therefore you do not automatically have access to the rest of the network, nor do you have access to any confidential documents.
The exploit mentioned in the article doesn't rely on ssh being configured to connect directly to root. It relies on the attacker having gained root access on the box being ssh'd to by the sysadmin. Once the sysadmin has ssh'd to the comnpromised box (as any user) the attacker can then ssh to any other box the sysadmin has configured to use agent forwarding.
Two solutions to prevent this compromise of the rest of the network:
1) Don't allow the DMZ box to ssh anywhere; firewall it off. There should be no need to ssh FROM the DMZ box, only TO it.
2) Use a different public/private key pair for each box. That way, if you didn't firewall the DMZ off it would still fail on the key authentication. The drawback of this is a) the attacker can still ssh to your admin box which contains all of the private keys and b) you lose most of the advantage of agent forwarding; the ability to ssh through a chain of boxes without any but the first needing to store the private key.
I suppose the underlying message in the article is "You REALLY can't trust anything in a DMZ that may have been compromised. ssh is a tool that can be turned against you if one of your machines is compromised."
It's not just you. I had to re-read it several times.
I think the main point (the one the article submitter picked up on) was that if an attacker can compromise your DMZ box (the most vulnerable box your company owns and hence the least trusted box your company owns) that has no private ssh keys stored on it and can't connect to any other trusted box but does have trusted boxes connecting to it, then he can use that to compromise further trusted boxes inside the organisation.
To put it another way, if you ssh to an attacker's machine using agent forwarding he can probably ssh back to yours.
Maybe complacent was the wrong word; I was tired and not thinking correctly.
The question is now: how do you know that you haven't passed on a virus. Some are really obvious (Netsky comes to mind) when you receive them in an email but some (like thus.gen) aren't pretending to be from someone in a friend's address book; they are actually a legitemate email from a friend with a legitemate Word attachment that just happens to also contain a Macro virus.
If you forward it... you have passed on the infection. If you open it, you will have infected every Word document you open after that until you remove the infection (several ways to do that including deleting every infected Word file and re-installing Word but running a virus checker would also work) which means that any Word file you email would be infected.
Can you honestly say that you have never received a Word file in your email and either forwarded it on or opened it ? Never ? If so, well done but Word is only one example of a vector for executing cross-platform code.
The good news is that Macs don't suffer the symptoms because they don't allow MS Word the kind of access that the virus needs to the file system to do it's damage. (and also because I suspect that the virus exploits an error in the Windows version to run code in memory and not just interpreted macro code.)
Mistakes are inevitable but denying they exist, languishing before fixing them and claiming to have a "new focus on security" while continuing to produce bug and exploit ridden code is inexcusable. Unfortunately, the best I can do to punish them is to suggest to everyone that asks that they avoid these bug ridden products and use something more secure.
Don't forget that while you may not suffer from the symptoms of a virus you can still be a carrier.
.doc file infected with thus.gen. It was a macro virus and hence the macro part of it worked just fine on the Mac version of MS Office and infected the normal.dot file and therefore every file opened after the initial infection. It got to the point where something like 50% of the Word files in the organisation were infected and nobody knew... then we sent one to a goverment department who were all Windows-based and their virus scanner blocked it. After that, there was a mad rush to update the virus scanner on our mail server (hadn't been touched in three years) and provide tools for the users to remove the virus (I think it just stripped all macros from the Word docs but very few people in that organisation used macros anyway.)
I used work at a Mac-centric organisation that received a
Even other kinds of viruses can be re-transmitted by Mac users.
Feel free to enjoy your safety and complacency and keep evangelising Macs as much as you like but don't forget that you can inadvertantly pass on infections that you receive and damage other people's computers. Viruses are not a threat you can ignore just because you own a Mac.
I don't know about you but I don't find this funny anymore. It might have something to do with only one of the points actually being valid with respect to this article and even that one's only a "maybe".
In case you hadn't noticed, the government isn't actually advocating any particular approach but simply saying that you must take some approach to fighting spam or we'll fine you big time.
All this code has really done is to create a big stick that the government can use to whack ISPs who harbour spammers or who make it easy for spammers to operate. I'm sure this will improve the situation somewhat but three quarters of Australian ISPs will already comply with this code today, before it is enforced and the others are probably the small players. The market place demands that ISPs have spam filtering and virus scanning. Not sending out devices in default configuration is just common sense. Common sense is now legally mandated.
I suspect the point of the article was that it can now be done in realtime. The journalist may not have picked up that plotting traffic patterns was old hat but I'm sure the MIT researchers knew. Realtime traffic patterns would have many more uses than daily plots of the traffic patterns particularly in responding to emergencies.
The article uses the words "regular intervals" which doesn't really give us much idea of how often this is but "realtime" suggests that it's somewhere in the realm of every minute or several times a minute.
I like to think that researchers at MIT working on something that journalists report as "cutting edge" probably is cutting edge, however it may not be that the aspect of it the gets all the emphasis is actually the cutting edge part.
While that episode was funny, I have to disagree with the general sentiment of your post. I expect my scientists to be experts in their fields and I expect my journalists to be experts in the English language and writing styles. (English because I don't speak anything else... not because I expect everyone's journalists to write in English.)
Journalists should have to study enough from books and interviewing the scientists to write an accurate and informative article. Without their scientific books, they are just another English major but with them they are able to distil the information into a form that the masses can understand.
A teacher who is dependent on books can still be a good teacher as long as they still have their books. But someone who is not a good teacher will not be a good teacher even with their books.
There are two aspects; the knowledge and the skill (of writing for journalists or teaching for teachers). Without the skill, you have nothing but without the knowledge you can always look it up in books.
There are many other valid points raised in other posts but this post is purely about whether journalists should have to have a high level of knowledge of their subject for each and every article they write or whether they should be able to learn just enough to cover the article and then promptly forget it all in time for the next article on a different topic. It would probably be a good idea for the journalists to submit the article back to the scientists who are doing the research (or at least a scientist in a relevant field) for accuracy checking before publishing.