Downloading Software Safely Is Nearly Impossible
noncombatant.org
noncombatant.org
* Goal: "Download Firefox"
First, the user was using IE. And the user is not a tech savvy user (as in, cannot read words on the screen). Turns out, the user's computer was infested with spyware and garbageware. Mainly Conduit and others.
Evidently, user "searched" for firefox rather than follow my directions to type in the address bar https://www.mozilla.org . This behavior lead him here: http://firefox.en.softonic.com/
Normally, I would use a remote support tool and just do the cleaning for the user. However, this client comes from another area in which we are not allowed to use the remote support tool.
In the end, I tried to have user uninstall the bad-firefox, and attempt to install the good, but the softonic installer installs a ton of crap everywhere. User got very frustrated and hung up when having him read the uninstall programs installed list. *
That is the danger to most users, running Windows.
EDIT: For the user whom penalized my comment score, why?
Dealing with Windows nowadays is akin to cleaning a septic tank. I wish I was kidding
I'm thinking someone should build a (Linux or other *IX) that scans the HD of an infected machine (booted with this distro or the HD was removed and put on another machine) to scan and remove everything. Working directly on Windows is impossible
Among other things, it boots a live linux CD that's packaged with a handful of 3-5 antivirus scanners.
I don't think that would be all that useful. If you have a malware-infected system then your focus should be rescuing user data, and not cleaning the infection (which is pretty much impossible to do reliably).
Good luck figuring out if the user data is the cause of further infections. Add some infected pdf, tif, jpg files and it could come right back. In the terms of less common applications there are likely thousands of libraries used by these programs with data interpretation exploits waiting to be be found.
Kaspersky did it.
and AVG: http://www.avg.com/us-en/download.prd-arl
although I am not sure if they are linux based.
(And I still see a fair number of Linux install scripts that look like "curl ... | sh")
Linux does not have "your mouse pointer moved. Are you sure you want to proceed?" dialogs.
Linux has a manageable set of file permissions, including the "execute" permission being set by the users, not by any random server from where you download your file. (Yep, there was some regression here lately.)
And, of course, Linux is actually hard to compromise without user intervention. Differently from Windows.
If you really believe it's the users fault, you have your head deep buried on the sand.
`curl http://example.com/foo/install.sh | sudo sh`
Equally bad is adding a new key to apt/(other package manager) and add a new source then apt-get install (which definitely runs as root).
Hunting the Internet to track down random dependencies, watching freshmeat.net every day for new releases, and fighting with all of the different build systems was what I did every day ca. 1997.
In other words, installing (and upgrading!) software in Windows has not made much progress since 1997. I blame MS's decision "oh sure, you can integrate your program into Windows Update, it will only cost you $BigBucks per year."
1. The user clicks yes. They might read what they clicked yes to.
2. The user doesn't usually read prompts
3. The user will not read error messages, even if they are to their benefit.
4. The user doesn't know how to "google" problems
5. The user will sometimes even ignore IT professional help even when they call us. This is usually a "bitch session" with no clear resolution.
6. You will tell the user what to do, and they will also say yes. They still don't understand.
7. Users will install software and not understand how to remove said software (control panel<remove software).
8. Users are not curious. What would be obvious to simple reading they will ignore.
9. Only when the computing environment is unbearable, will they call in. Or it will be the simpleton user who wants you to do their work for them.I was shocked by how many forks of PuTTY there are -- and most suck: https://github.com/FauxFaux/PuTTYTray/wiki/Other-forks-of-Pu...
Many recommend KiTTY but with an ad supported site that complains about adblock when you go SSL (after a warning) and includes hidden features -- well, that's not something I'd trust either.
Probably because you claimed that the example was contrived when it is actually very real, and is something many visitors to HN have specifically faced, and is a particularly ironic case given that the target software is critical security software, given essentially the keys to the lands.
Ultimately many of us simply have to assume that Google's pagerank is the surest sign of the credibility of a link, but of course we know that can be gamed. And even had this site been on an appropriate domain with HTTPS, even that shows little given the completely lack of vigilance by most SSL cert firms now (partly at the behest of the tech community who find the cert process annoying and expensive).
1. There was no mention of http://putty.en.softonic.com/
2. If you are looking for an SSH client, you are not a normal user and should know that CYGWin or Putty are freely available.
3. Using whois is considered more advanced end-user techniques.
4. Continual complaints that the download server doesn't have SSL. It's annoying and bad. Trying it again and again is kind of pointless. You made your point.
5. Tries to get the author's key via the MIT PGP server. This is NOT end-user stuff here.Did he claim it was? How is that relevant?
I've mentioned it a few times on here before[1], even directly to Google employees[2] and they don't seem to give a shit at all. I've even noticed searches for Chrome sometimes show links to (what appear to be) malware sites now[3]. Maybe that will motivate them to sort this out but I'm not hopeful.
Putting my conspiracy hat on; it seems like there isn't much motivation for Google to sort out the problem because every new malware loaded PC is another potential convert to a locked down cloud based platform like ChromeOS. There isn't really much downside for them in making Windows as horrendously unsafe for non-experts to use as possible. Why Mozilla aren't screaming about it constantly is more of a mystery to me.
[1] https://news.ycombinator.com/item?id=7101939
The problem with a search engine is that there's no lock-in other than brand recognition. Google won over AltaVista and Yahoo by being superior. I still remember the first time I tried it, it was so much better that it made an instant convert out of me, even though typing "altavista.com" was rooted in my nervous system and this was in the days before they were big, before AdSense/AdWords/AdX. And I could see it at Internet Cafes catching like fire, within mixtures of technically oriented and unsophisticated users alike.
And it can happen again. What pains do normal users have when using Google lately? Malware, content farms, "aggregators", too many ads. The only reason for why Google is still number 1 with a near monopoly is because there is no better alternative. DuckDuck Go is awful for me. Bing too. You may not notice how awful they are, unless you're living outside the US.
And I'm pretty sure they know that they can lose users fast. And once a significant chunk of users are gone, advertisers will be gone too. That's why Android exists in the first place, though distributing Bing as the default doesn't really help Microsoft, so having your own platform only protects you against walled gardens. And there's even a bigger danger therein. Google doesn't even have to lose users for advertisers to leave - Google already knows that the majority of clicks on all served ads are done by a minority and advertisers are increasingly aware of this fact too, as quality conversions are going down. This is because targeting is not so good after all and because users are increasingly fed up with spamy results and annoying ads that aren't targeted well.
I think their problem is that they are trying to solve this through algorithms only. The problem with algorithms is that algorithms can be gamed, you only need to find the ranking formula, which can of course be done through trial and error. It's a whac-a-mole game basically.
But for popular searches, like Firefox, they could have exceptions in there to propel those as first results. Is it not obvious that users searching for Firefox actually want Firefox, the browser from Mozilla.com, in spite of Mozilla.com's ranking? Is this against their policy or something? And now that they have Google+ accounts, why don't they add a "Report Result" button? If flagging email as Spam in GMail works so well, why didn't they do the same thing for their search engine?
This is not quite true. The 'lock in' are the advertising channels. If you want to replace Google you need replace their lock on advertisers. I have direct visibility into the effectiveness of Google's, Yahoo's, Microsoft's and third party advertising networks, I can state with certainty that if Microsoft was able to show Google advertising feeds on their search property, even with Google taking 20 - 30% off the top, it would be Microsoft's most profitable division, swamping the profits from either the Windows licensing stream or the Office licensing stream.
However, the limited _user_ lock-in means that a 'better' search engine could take user share, which would then make it more attractive to advertisers.
Considering that what most Windows crapware installers do is mercilessly track users for the purposes of marketing and that Google's main business is tracking users mercilessly for the purpose of marketing, it is hard to see how this is some random event.
Google's definition of "best search results" is related to their bottom line, and the goal is to be as intrusive as possible without driving searches away. This is why the Google ad network laden "weather.com" is returned before the ad free and purely scientific "weather.gov" from a US search for "weather."
For real fun, search for "pdf to html" and "pdf to html linux" to compare the degree to which Google promotes solutions that collect data on users. A Windows user would never know that a free quick private and powerful alternative is just one VM away.
This isn't a conspiracy. It's basic business and doing otherwise would be the basis for a tort.
This is a case where I posted in a rush. The basic idea that Google's ranking algorithm is optimized to serve Google's interests first and those of its customers second is the only possible way for Google's officers to fulfill their legal obligations to the shareholders they serve.
The key to understanding this idea of the best search ranking algorithm is that people who query Google's search engine are not Google's paying customers. Google Search's paying customers are almost exclusively advertisers.
The best search results Google can produce are those which maximize their revenue. Not enough traffic directed to ad buying customers and advertising dollars may go somewhere else. Sure too much obvious selling might drive queries elsewhere but the threshold for tolerating advertising keeps going up. So many people take tracking across sites for granted that Google can push a "weather" search onto an advertising affiliate's site and still meet the expectations of the data point making the query. There is no objective reason other than income for ranking secondary sources above the primary source, "weather.gov".
Occam's razor just cutts that way.
It's true that searchers don't pay Google money, and advertisers do. But Google is running a platform. In the past I've compared it to an information marketplace. And the goal for Google is to make the market run as efficiently as possible, otherwise they risk losing one side.
Searchers don't pay Google, but they do (presumably) pay Google's advertisers, who pay Google. If you lose the searchers, you lose the advertisers.
Now of course there is a balancing act, which you allude to in your last paragraph. But there are plenty of easy examples where Google returns no ads even though they could. A search for "how old is barack obama" just returns the number (or Wikipedia), without ads, even though I'm sure there are advertisers out there who would pay for an ad to be shown.
So obviously it's not universally true that "the best search results Google can produce are those which maximize their revenue." Perhaps adding some subtlety to your argument would help me understand exactly what you're saying.
For example Google Search might be considered a marketplace, but such an abstraction might lead a person to lump buyers and sellers into amorphous blobs and ignore the heterogeneity within each group. Ford and overstock.com are different sorts of advertisers and thus Google's business comes down to segmenting end users.
Plain and simple the most valuable end user segments are people who not just tolerate tracking and targeted advertising but who actually derive value from it. They are valuable not only because they click through and buy stuff but because they validate Google's claims that its business of tracking users and pushing ads and tailoring search results toward commercial interests and away from the long tail is objective.
Long tail results are not revenue generating and Google has simply removed bit by bit the end user's ability to specify them. Sure spelling correction is useful, until Google search refuses to respect quotation marks and simply renders some terms unreachable. Local search is useful, until a person wants to search across borders or outside their local language.
In Google's case, their officers are responsible for optimizing the mix of objective search results with revenue producing search results. That optimum can be described as just good enough not to drive too many queries away while maximizing clicks to their customers. There's no legal requirement or demand from shareholders for a wall.
And indeed the very idea of tailoring search results to an individual's past browsing history is always going to push sites that share data with Google to the top of the results page.
TANSTAAFL.
Short-term-ism in terms of maximizing ads revenue which costs long-term goodwill is a serious negative for Google.
I'd argue that in the past year or three, the company has started showing its vulnerabilities. I'm not sure who will take over from it, or how, or what that company's business model will be, but I see vulnerabilities.
The dynamic Google results page means that it's really difficult to refine a search based on the presently visible results which disappear as I update the search. I find that that behavior incredibly annoying, and greatly appreciate that DDG doesn't do this.
Or when I put an entire error message in quotes and it deems the number of results for that error message too low to be intentional so it deconstructs it into a useless mashy search of all the words in the error. Note, I don't mean when the results are zero, but even then I usually have to spend an annoying amount of time before I realize that my search actually had zero results instead of the millions it claims it had.
There was a time when google's cleverness was just enough to be useful, but it gets more and more clever (and frustrating) every year now.
It's much better than the first time around: more relevant, faster, and very few technical hangups.
I still fall back to Google periodically, especially for:
• Date-bounded search. DDG doesn't support this.
• Specialty searches: news, books, scholar. I've also keyed up custom searches for a bunch of sites in my browser.
• Rarely: I don't seem to find what I'm looking for on DDG. Usually first an !sp re-search, if that fails, !g. About 2 times out of 3, I still don't find what I'm looking for and return to DDG for more refinement.
Google has a dual class stock. The only shareholders with any power are Larry and Sergy. That was done to avoid short term thinking (precisely like you are proposing). Investors know this when they buy on.
The constantly repeated 'duty to maximize shareholder value' line is nothing more than a myth.
In the case of Google, the triangle of Page / Brin / Schmidt basically control Google outright, regardless of the other shareholders, due to their voting shares. So they absolutely do not have any duty what-so-ever to maximize anything. Buyer beware, is basically what they stapled to the prospectus.
http://investor.google.com/corporate/2004/ipo-founders-lette...
In fact it's no more complicated than this: if some random shareholder is upset, they can stir the pot accordingly, and the waves they'll make is almost always in proportion to the shares they can vote directly or indirectly. There is no singular objective qualification on what would lead to the maximization of shareholder value, it's an opinion that varies from one shareholder to the next as to what they think is "best" for the company.
Simple example: some shareholders might think it'd be better to slash salaries at Costco to boost the bottom line. Others believe part of the reason Costco is so successful is their employee culture.
The search algorithm is not the only tool in the ranking as we know google has a way to penalize a specific website among others.
Also, it's not just malware. Google also makes money by promoting scam sites that charge people for free government services.
Google's malicious advertising is the number one reason that we're able to justify installing AdBlock Plus on every client's system (we talk to them about it first) and disabling ABP's new "feature" to "allow non-intrusive advertising".
Sites that depend on ad revenue should be screaming at Google to fix this.
Google does care, and will take action to disable malicious advertising. For many of these sites, there is no obvious badness on either the ad or the landing page, so a manual report will help us fix malicious advertising.
I work on some small portion of Google's systems related to automatic malware scanning (albeit, not anything that would show up on the search results page), and I want to make sure that we don't direct people to malicious advertising.
But: as an experiment, I just turned off ABP and Google'd (heh) "yahoo support". One of the ads at the top was for http://www.aurasupport.com/email_service; at a quick glance, I see a website template from http://pixel-industry.com/website/, lots of broken English, and a domain that was registered just last Summer to a house address in a suburban development in Texas. Not exactly a smoking gun, but also probably not what somebody's looking for when they search for "Yahoo support"...
And, farther down the first page of the actual search results is http://www.yahoosupport.org/, which has a toll-free phone number in the title, 1-888-551-2881. Googling that phone number takes you down a rabbit hole of lots of dirty SEO (e.g. https://www.youtube.com/watch?v=AEO5-2RpYvo), no actual customer reviews anywhere, and offers for support for lots of services -- including, uhm, Gmail (http://www.password-recovery.us/contact-us, look at the page title).
So, I'll be happy to use the link you gave, but this seems to be a fairly serious problem, and I'm a little surprised that Google doesn't have a better handle on this.
Is it something you can easily and obviously do, in place, when you find links to spam & malware sites?
Or do you have to know a special URL?
All but one of the badware ads I reported disappeared, within 20 minutes too! (but why one remained I have no idea!)
http://blog.dynamoo.com/2013/10/google-ads-and-fff7ed-whats-...
1. proselytism 2. grammatical solecism 3. inflating the value of a "downvote"
In hindsight, I should have kept my mouth shut. But hit those three before my caffeine deficiency has been addressed, and I'll likely find myself in _that_ role.
Is there any other kind? I will admit the whom-bomb was unpleasant.
OP: If the answer is not him/her the question is probably not "whom."
You're recovering from a system compromise, an unrelated problem from downloading Firefox. Hints to get started: unplug net, image the HD for later forensics, reformat & reinstall OS, carefully restore non-executable data files from backup.
Our service is mainly troubleshooting simple and mild problems, and escalating difficult issues to the relevant departments. A problem like spyware is a constant in our job, causing problems ranging from system instability to mal-rendering web pages.
Ideally, a backup/wipe/reinstall is the idea solution here, BUT these are regular non-tech-savy users. The computer is a means to an end here. "It goes beep-blip-boop that my teacher wants" is the kind of thought. Explaining that a reinstall is ideal is ignoring the fact that this operation would cost ~200$ at Best Buy or similar place.
Frankly, I use what tools I can. If that means manually uninstalling what I know is spyware, rebooting in safe mode and running Malware Bytes, I'll do exactly that. At least it triages the problem until next week when the user goes and downloads something Adfly or Softonic... again.
The problem is Windows. IE is too easy to hack and break. Drive-by exploits are routine with IE and Windows-Firefox. There is little security and process limitation in Windows to prevent an active expoit. Worse yet, I cant even delete an "open file" without special tools. In any other OS, that's not a problem. File gets removed. Windows acts like a toddler.
BTW, Xubuntu works well here for friends and family whom I support. It just works, they're nigh invulnerable to exploits and problems are a kill and rm away.
However, consider how distros generate their signed binaries:
1) A packager downloads a random tarball off the internet, often over HTTP and/or unsigned and unverified.
2) The packager uploads the same tarball to the distro build system (you trust them, right?)
3) The packager's script for building the program or library is executed by the build server (you trust all of the packagers, right? they have implicit root access to your machine during pkg install.)
4) The packager's script likely invokes `./configure` or similar. Now even if you trust the packager, the downloaded source has arbitrary code execution. You verified it, right???
(Not trying to advocate for webcrypto. And I'm a Linux user. But I'm also a packager, and I have some awareness as to how one would go about pwning all users of my distro.)
Then they're being remiss in their duties.
> 2) The packager uploads the same tarball to the distro build system (you trust them, right?)
Yes, I do.
> 3) The packager's script for building the program or library is executed by the build server (you trust all of the packagers, right? they have implicit root access to your machine during pkg install.)
There is at least traceability here. There are a large number of packagers for my distro, true - but they are required to personally sign for the packages they upload. If one of them turned out to be malicious, I don't think this would be without consequence.
First the identity of that person would be stigmatized to a point where it wouldn't be usable anymore to gain trust to other projects. Publishing rights certainly would get revoked for that user.
Then all packages published by him/her will need to be analyzed for further exploits and discussions would happen to avoid future similar issue. If possible a patch/fix would get published by the distribution.
The key is to limit the number of people you trust and remove instances where you mistakenly trust more people than you believe you do. When downloading a .exe over http, you trust an unknown number of people working at each company your packets hop over to reach the server. You are implicitly trusting each and everyone of an unknown number of people with direct root access.
With a Linux distro this is different: you are trusting the distro and any employees/volunteers of that distro. You trust that the distro is actively vetting the people involved - or is at least in a position to publicly name them if they break the trust of users, etc. Ultimately you do still have to trust someone, though.
Debian, at least, has proven to be fairly trustworthy so far. Who has access to ae-5.r23.londen03.uk.bb.gin.ntt.net and what do I do if they MITM my traffic? EDIT: Any why can't they spell London correctly?
Do you have any actual evidence that Linux distros do packaging this way?
But I'm also a packager, and I have some awareness as to how one would go about pwning all users of my distro.
And do you actually do so? If so, please tell me which distro you package for so I can avoid using it. If not, why do you think other packagers do?
As an example, let's compare the way two distros (Fedora and Debian) package an old piece of software: aumix.
Taking a look at this spec file [1] for fedora, we see two pieces of metadata: a URL to a homepage, and a URL to the software. The URL is not used for packaging at all; it's merely a reference. The URL to the file can be used to download the software, but if the file is found locally, it is not downloaded. And guess what? That source file is provided locally along with the other source files and patches in a source package. So whatever source file we have is what we're building. This file doesn't contain a reference to any hashes of the source code, but the sources file [2] in Fedora's repo does.
With Debian we have a control file [3] that defines most of the metadata for the package. Here you'll find a homepage link, which again isn't used for builds. The path to a download is contained in a 'watch' file [4], which is again not referenced if source is provided, and generally only used to find updated versions of the software. There are no checksums anywhere of the source used.
The source to aumix actually provides its own packaging file [5], provided by the authors. Apparently the URL used here is an FTP mirror, not the HTTP mirror provided by the earlier packagers. Could that be intentional or a mistake? And could they possibly be providing different source code, especially considering the hosts themselves are different?
It's clear that there's a lack of any defined standard of securely downloading the source used in packages, much less a way of determining if the original author's source checksum is the same as the packager's source checksum. There are several points where the source could be modified and nobody would know about it, before the distro signs it as 'official'.
[1] http://pkgs.fedoraproject.org/cgit/aumix.git/tree/aumix.spec... [2] http://pkgs.fedoraproject.org/cgit/aumix.git/tree/sources?h=... [3] http://anonscm.debian.org/viewvc/collab-maint/deb-maint/aumi... [4] http://anonscm.debian.org/viewvc/collab-maint/deb-maint/aumi... [5] http://sources.debian.net/src/aumix/2.9.1-2/packaging/aumix....
But this is still secondary to the basic point: as a Linux user, I get packages from my distro, not from the upstream source, so I don't have to go searching around the Internet for packages or package updates, wondering whether I've got the right source, wondering why there isn't an https URL for it, etc., which is what Windows users have to do according to the article (and OS X users too, for the most part, though the article doesn't talk about that). The distro does all that, and either I trust them to do it or I don't (in which case I go find another distro). The fact that the distro doesn't make it easy for me, the user, to see how they verify the sources they use, does not mean they aren't verifying the sources they use.
Also, while it's true that the distro verification process is human-fallible, as you say, and it would be nice if every OSS project made it easy for distros to automate the process instead, it's still a lot less human fallible than having every single user go searching around the Internet for software. Distro packagers at least have some understanding of what they're doing, and they at least know who the authoritative source for a particular package is supposed to be without having to depend on Google's page rank algorithm.
Is searching for, downloading and installing Putty actually resulting in users with malware-laden files? It would seem not, as the highest-ranking results for Putty are the official ones, and downloading/installing is a breeze once you get to the official page.
For software that's a more likely target for scams (like Firefox) you'll find a lot more user error and potential for abuse. And consider that many users may download and install Firefox by hand instead of using their distro (it's faster and less complicated). And similar to the attack on popular Windows end-user software, Linux server software is often a more high-value target for attack also results in users unknowingly installing insecure software, as we've seen in[1] many[2] cases[3].
Realistically the only thing keeping Linux more safe is that the user base and culture are different. But it would be naive to assume that somehow distro packagers are a more trustworthy source of files than the ones you could find on your own. It would seem to completely depend on the application and the user.
[1] http://www.darkreading.com/attacks-breaches/open-source-proj... [2] http://arstechnica.com/business/2012/02/malicious-backdoor-i... [3] https://security.stackexchange.com/questions/23334/example-o...
One of them being that you typically must be root to install packages. This mean that if anyone manages to slip a backdoor in any moderately used package, it probably means "root" on many Linux systems.
Some people have been complaining about that for years. Thankfully we're now beginning to see things like "functional package managers", where packages can not only be installed without admin rights but can also be "reverted" back to exactly the same "pre-package-installation" state if wanted.
The other very serious issue is that most package builds are not deterministic. I think everybody should begin to take security very seriously into account and realize that deterministic are the first (and certainly not only) step to take towards software which can be trusted a bit more.
There are thankfully quite some people who are now taking the deterministic builds route and one day we should, at last, be able to create the exact same package on different architectures and cross-check that we've got the same results. This won't help with backdoors already present in the source code but it's already going to be a huge step forward.
So, yup, I take it that, of course, as a packager you know how to pwn all your users.
As a user I wish we had a) deterministic builds, b) functional package managers, c) packages which can be installed without being root.
If we had that, there would be less ways to pwn all the users of one package at once. I'm a Debian user since forever (and I love the rock-stable Debian distro) and I'm not expecting Debian and other big distros to move to such a scheme anytime soon (it's probably too complicated) but there may be a real opportunity here for newer distros who'd want to focus on security.
./configure --prefix=$HOME/opt/$pkgname && make && make install
> but can also be "reverted" back to exactly the same "pre-package-installation" state if wanted.
For system-wide packages, most package managers do support this. Since they don't support user-only packages, of course reverting an install isn't going to happen.
If you've installed it yourself, `rm -rf $HOME/opt/$pkgname`.
> The other very serious issue is that most package builds are not deterministic.
Deterministic builds are hard.
> be able to create the exact same package on different architectures and cross-check that we've got the same results
Unless you're cross-compiling, different architectures by definition nets you different builds. Even within an architecture, differences in feature sets (take advantage of Intel's shiniest instruction?) and compile time options (use this library?), where to install, etc. cause the number of possible build combinations to multiply quickly. Binary distros like Debian have it a bit easier, as they usually distribute a lowest-common-denominator binary with all features, but some distributions (I'm a Gentoo user) let you tune the system more.
Even if you had all the things you name, you still have to trust whomever is packaging your software. Or build it yourself after reading the entire source. (And then there's the chicken-and-egg problem with the compiler.)
mkdir ~/opt/xstow
cd /tmp
# get package (verify signature)
cd package
./cofigure --prefix=$HOME/opt
make
make install prefix=$HOME/opt/xstow/package-version
cd ~/opt/xstow
xstow package-version # xstow -D to "uninstall"
Some packages are a little harder, but can sometimes be tricked to behave by moving ~/opt/xstow out of the way, doing a make install and then moving ~/opt to ~/opt/xstow/package-version-etc and xstow'ing.
It's virtually impossible to create deterministic builds of common software. There's random sources of data and variables all over the place. And more importantly, deterministic software != secure software. You could make a perfectly deterministic piece of code, compile it, run it, all the same on all hosts. It can still be rife with security holes.
I don't know what you mean by 'functional package managers'. There's plenty of 'functional' package management software out there used by millions of people every day. If you just mean easier to use, there's that too.
You can already install software without being root, very easily in fact. It just won't work very well because a lot of software is designed to operate with varying levels of user and group permissions, and varying system capabilities. And again, more importantly, there are plenty of privilege escalation exploits released all the time that could get to root from your user. Malware doesn't even need to be root if all it wants is control over your browser sessions or to siphon off your data. Root-installed software is as big a deal to a single user system as a vuln in your copy of Adobe Flash.
Nope, it's definitely not. If projects like Tor and Mozilla (they're working on it) can do it, then the 99.99% of packages out there which are less complicated than Tor / Mozilla can do it too.
> It can still be rife with security holes.
You're just rewriting what I wrote: I didn't said it would mean the software would be secure. I wrote it would already be a huge step forward.
> "I don't know what you mean by 'functional package managers'."
I mean for example this:
nixos.org
> Root-installed software is as big a deal to a single user system as a vuln in your copy of Adobe Flash.
Definitely not. Especially in a system like Linux where it's easy to have multiple user accounts (including one used just for surfing). I'm a "single user" and I do have several user accounts on a single machine (including a user account which I use only for surfing the Web). No Adobe Flash here btw and no Java applets either (I'm a dev and I do typically target the JVM, but there's no way I'm allowing Java applets in a browser) ^ ^
You say: "deterministic builds cannot be done", "there's no point in having deterministic builds because there could still be security holes", "local exploit is as bad as root exploit on a single-user machine"...
And I disagree with all that. And thankfully there are people disagreeing with you too and working on tomorrow's software packaging/delivery methods.
I thank Tor, for example, for showing us the way. The mindset really need to change from: "it cannot be done, it's too complicated" to "we can do it, let's follow the lead of the software projects showing the way". There's a very real benefit for users.
The "why":
https://blog.torproject.org/blog/deterministic-builds-part-o...
The "how":
https://blog.torproject.org/blog/deterministic-builds-part-t...
Honestly I simply cannot understand why there are still people arguing that deterministic builds aren't a good thing or people arguing that it cannot be done.
It can be done. And it's a good thing.
Unless the packager is on the mailing list for the project, which many are as it helps them keep up to date on changes.
"The packager uploads the same tarball to the distro build system (you trust them, right?)"
Now the package is in one place, so when you say, "SSH on Fedora seems to open a connection to this random server in Ft. Meade!!!" everyone else can check and see if that is what is happening. Now you have thousands of people investigating the bug -- not so bad. Compare this to, "I downloaded something that is supposed to be PuTTY, which I found via a Google search, and it is acting funny!"
The fact that everyone who uses Fedora or Ubuntu is running the same code is pretty helpful. It is not much, but it does help.
"The packager's script for building the program or library is executed by the build server"
In a chroot jail, or an SELinux sandbox, or a VM, or any number of other environments that help to isolate the build process from the rest of the system. In theory, the build server has quite a bit of protection from malicious packagers.
Also worth noting is that packagers' actions are logged and would probably be audited if a user sounded the alarm and nobody could figure out what was happening. It would take a lot to pwn the users of a distro in any meaningful way, because keeping it secret is hard -- your victory would be short-lived.
http://askubuntu.com/questions/28372/how-do-i-get-the-source...
When you do that you'll get the original tarball that was used to create the package along with any patches. You can compare that tarball to one you can find on the Internet (usually in more than one location) and they usually have md5/sha1 signatures.
The rabbit hole goes very deep and yet there are people (like me!) who actually do do that sometimes. I suspected that the tuxtyping package may have been modified (due to corrupt .wav files being included) and went through the whole rigamarole of validation. I double and triple-checked the signatures against the binaries, sources, and everything else I could find in the package repositories (and mirrors).
Turns out it was just some filesystem corruption that added some extra bytes to the tail end of those .wav files. They're harmless.
1) packagers have a history with their packages. They fetch from the same source, verify with the existing GPG key, etc. They aren't fetching from a different random source for each build. As part of the package review process the upstream source should be reviewed and confirmed.
2) Everyone in the distribution is using the same code. Unlike Windows/OSX the users get the same binaries from a single source. This allows problems to be corrected quickly for everyone at the same time.
Repro steps (Windows 8.1, desktop IE 11 or Chrome 33):
1. Download putty.exe from any shady source
2. PuTTY runs without prompting
3. go to mega.co.nz (an extremely shady source), upload your copy of putty.exe
4. download it again
5. this version of putty.exe also runs without prompting
6. open your hex editor of choice, change a byte in a text string
7. upload this tampered version of putty.exe to mega.co.nz
8. download and run it
9. observe full-screen modal red banner: "Windows Protected Your Computer" requesting an Administrator password to run suspicious binaries.
(I don't know which is true, but if we're speculating, I imagine the latter would be more realistic than a huge checksum database bundled with the OS. Though maybe it's a small checksum database that only includes the personal favourite tools of the windows developers? :P )
Checking with a valid but extremely uncommon downloaded binary shows the same red banner (as well as a Chrome warning).
Just a note - PGP signing renders HTTPS useless for downloading the binaries themselves and works by establishing a chain of trust, the problem is with distributing the public key. It's the public key that must be distributed either over HTTPS and/or through a public key server, letting other users digitally sign your certificate and thus endorse the association of this public key - a system that works great for popular repositories of software (e.g. Debian), in which the participating developers/maintainers know each other. Once the authenticity of the public key is correctly established, there's no way for an attacker to create/forge the signed binary, unless said attacker gets ahold of the private key, which is way more difficult than hacking a web server, as normally private keys don't end up on those servers (so it is more secure than HTTPS). For example, in Ubuntu if you're willing to install packages from PPAs of third-parties, you first need to indicate that you trust the public key with which those packages were signed, otherwise apt-get will refuse to install said packages.
A reasonable alternative to PGP signing is S/MIME signing, which is more user-friendly, as it doesn't involve the users vetting scheme, but rather certificates are issued by a certificate authority, just like with HTTPS/SSL. S/MIME is weaker against the NSA, but it does work well for signing stuff and it's more user friendly, because to establish trust, you only have to trust the certificate authority (and of course the developer).
Binaries on OS X are also distributed as signed with the developer's key and OS X refuses to install unsigned binaries or binaries signed by unknown developers, unless you force it to. And while I have mixed feelings about the App Store direction in which Apple is taking OS X, I've began to like this restriction, in spite of the money you have to pay yearly to register as a developer (as long as you can download signed binaries straight from the Internet and thus not completely locked into Apple's walled garden, it's all good). Signing binaries and having a user-friendly way to establish trust in the used signing key should be the norm in all operating systems.
http://msdn.microsoft.com/en-us/library/ie/ms537361(v=vs.85)...
If I still ran a bunch of Windows machines used to access the internet I'd be seriously attempting to run with group policy set to block unsigned executables and, eventually, trimming the of trusted code signing CAs as well.
Is this policy not enabled by default in the various versions of Windows? I think it is in Windows 8, right? What about 7? And why don't developers use it?
1. Because a code signiging certificates are not cheap (although with some tricks you can shrink the prize a lot: http://stackoverflow.com/questions/3091938/cheap-code-signin...)
2. Because code signing is snake oil. Lots of malware is signed even with leaked driver certificates of some Asian hardware manifacturers; thus getting some leaked code signing certificate should be easy if you are used to writing malware.
Debian/Ubuntu's main repositories work by vetting for the maintainers that package the official binaries, with the proper keys being distributed as part of those distros. OS X works by validating if the key is a developer registered with Apple.
No system is perfect, I'm sure there's plenty of malware available for Debian/Ubuntu or OS X, including repackaged popular software that looks almost legit to the unsuspecting eyes, but this process works much better if you can have a second authority (in addition to the certificate authority) that is able to say "this developer did bad things so his key is no longer considered valid" and this authority must be the maintainer/governor of the operating system as there's nobody else that really cares about malware. For Debian/Ubuntu that would be the community / Canonical, for Windows that would be Microsoft, for OS X that would be Apple.
So what this means is that code signing does not work for redistributable software or for hard media very well. Ideally it would work if you have a single trusted online source for signatures but then this renders the system far less useful for many applications.
I am not sold on code signing. We sign our code and centrally publish the signatures separate from the code, so that while the code may be signed, the signatures can be updated if we need to change the key.
It's not that the developer does something bad but that if you can't revoke a compromised key effectively and safely for all parties, then you can't revoke it at all. And code signing in its current incarnations (whether with RPMs or MSIs) has serious problems there.
Another reason not to use it is that some developers have tried A/B split tests and found that users are slightly less likely to install the signed version. It will depend on your userbase, of course.
Sorry for slightly off topic message, but do NOT buy comodo code signing certificate, especially if you are a person and not a business.
Their verifying procedures are really insane and their support terrible. That's probably why are they so cheap.
If you want a reason to be wary of Comodo, there's the Comodo security breach incident to consider: http://www.infoworld.com/t/authentication/weaknesses-in-ssl-...
We paid $397 for a two-year code signing cert with DigiCert. Extended validation, which we would have happily paid for, costs about 2x but require physical access to our build server (which we don't have, using Azure / EC2.)
The price we paid for our code signing cert is comparable with the SSL star cert that we use - probably actually cheaper on an annual basis.
If you don't use it, IE gives you scary warnings that you have to fight through to download the software.
Most installers for windows software are signed. I just checked my downloads folder and of the more than a dozen installers in there every one was signed.
Now, not only do you have to use some weird kludge like Mingw or Cygwin to get an autotools-based program to build on Windows, you now have to either pay a bazillion dollars to some shadowy certificate cartel in order to produce a binary, or convince users to click through a scary-looking dialog which assures them your program is an evil virus that will steal their data, format their hard drive, and empty their bank account.
It's nothing more than a protection racket -- "Sure would be a shame if 'somebody' started telling users malicious lies about your program...Now, about our fee..."
Aren't we talking about a fee on the order of one developer hour per year? I share the annoyance that there isn't a better way to handle trustworthiness but look at it from Microsoft perspective: the odds are actually quite good that your users are seeing that scary dialog because someone actually is trying to scam them into installing adware, trojans, etc. which will degrade their system and almost certainly lead to complaints about how slow / buggy Windows is.
I think the long-term answer is going to look a lot like Apple's sandboxing on OS X: app-level permissions and scariness of dialogs proportionate to how much access an app wants outside of that sandbox. Until that's widely accepted, people are going to double-down on the code-signing path and that's going to lead to a lot of intentional slowness in the verification process. This sucks but I don't see a better solution with the current security models.
If you had used duckduckgo, you would have known better:
Official site. It's one of my favourite DDG features. It's just weird how Google doesn't have it.
It's really AOL keywords all over again - nothing bad, but just not Google's style.
Granted, DDG does give better results for "windows ssh client".
I don't use DDG because it's awful for users not living in the US. I'm not talking about the interface, but about local results. It also doesn't get the context well - when I search for Ruby or Python on Google, I get different results than my wife does ;-)
That's weird; when I just tried ddg, the correct site was first and putty.org was second.
Then I tried 'putty' alone on DDG. I got a Wikipedia-style disambiguation (cool!), and clicking the obvious alternative lead directly to the chiark result, this time bearing an "Official site" badge.
[^1]: Reflections on Trusting Trust. ACM Turing Award Lecture, 1984, https://dl.acm.org/citation.cfm?id=358210
Since then, I think I've actually become less security conscious though. The sheer number of ways you as a user of any of the useful parts of the internet are screwed is mind boggling. At some point, you just throw your hands up in disgust.
To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software.
My reaction was to the statement which I replied to. I would take that either as a summary of the document or your conclusion on the document.
Is it necessary to only comment after a full reading and understanding of the base document that someone is summarizing?
If someone pulls out a phrase "The press must learn that misguided use of a computer is no more amazing than drunk driving of an automobile." (from the same document) I think that stands on its own as worthy of replying back to without seeing what else has been written that might clarify it. I don't think this is cherry picking and pulling things out of context either.
In my opinion, yes. I don't know how to say it politely so I apologize for the abrasiveness: I think that when someone comments on something with little to no knowledge of the subject they are talking out of their ass. I try to avoid doing this because it seems like a waste of time for everyone involved and is therefore rude to other members of the community who want to engage in an intelligent discussion.
> I don't think this is cherry picking and pulling things out of context either.
How would you know? Without reading the document you have no idea what the context is.
Secondly, if you read it, you will recognize that what he is talking about is a real issue, particularly in the post-Snowden era and is totally relevant to the article. And his point really is that you can never be sure there isn't a backdoor planted somewhere in your software or hardware. Even if you write all the code yourself, it is still operating in an environment that you did not build.
Understanding this problem at its root is the beginning of an understanding into why depth is so important to IT security and why all our current approaches at trusted binaries are inadequate at least on their own.
What can you say to someone that thinks Ken Thompson has no relevance in the modern world or thinks he does not need to read something in order to judge if the one sentence he pulled out was taken out of context?
That those who do not understand UNIX (or history!) are destined to reinvent it badly (shamelessly stealing from Harry Spencer).
It really mirrors the historical reasons for feudalism in the real world. When the Roman empire collapsed, people needed protection from marauding hordes. So they cozied up to the nearest powerful group, forming kingdoms. People tolerated the abuses of kings and nobility in exchange for protection from anarchistic threats.
That's exactly what's happening to OSes: people are accepting feudalization in exchange for protection from malware.
Unless we find ways to really empower the user here, it's only going to get worse. We will end up with a fully feudal Internet.
Or in other words, despite clearly thinking they're the smartest people in the room, security programmers are dumber than shit when it comes to actually making it possible to use their software.
(If you insist on using windows, what about downloading SUA from microsoft themselves? That way you get a working SSH client without trusting anyone you weren't already trusting)
It's no wonder so many web developers use OS X or Linux.
They have excellent tools available for Windows developers. But step out of that silo and man, just forget it. You have to fight your own system every step of the way.
This is an example of a strategy tax (http://scripting.com/davenet/2001/04/30/strategyTax.html): Microsoft's strategy for a loooong time was to pretend like Windows was the only thing that existed. When Windows was a majority monoculture, this worked pretty well for them. But now that it's just one ecosystem among many, it forces their developer-tools people to pull their punches so as to avoid undercutting their Windows people.
What I don't understand is why Microsoft don't just include an ssh client in their software with some half decent key 'gui' key managing nik-naks. In that way your starting out web developer would not have any need to consider installing a linux distro.
Just by not having any linux friendly terminal they are inviting people to go dual boot which can end with them finding they don't need Windows or even Adobe as much as they thought they did. It makes as much sense as building the Berlin Wall.
I actually DO care about security and go to great lengths to secure my Windows 8.1 laptop and several physical Windows 2012 servers I maintain. If you know anything about security, it's actually pretty easy to secure a Windows machine.
One of the main reasons I'm stuck with MS is because there are no Adobe products available on Linux. The alternatives suck donkey balls and I hate Apple (too long of a story to get into here). Thus, I use Windows.
Full disclosure, I have several Linux boxes running Mint and an Ubuntu server and I'm actually quite fond of Linux. Unfortunately, a majority of my development is done with Adobe tools so I'm stuck. Give me a decent set of dev tools that mimic my Adobe tools (Fireworks, Illustrator (not Inkscape), Photoshop (not GimpShop), InDesign and now their Edge tools) and I'd drop MS in a heartbeat go 100% Linux.
> Neither the NT hash nor the LM hash is salted. Salting is a process that combines the password with a random numeric value (the salt) before computing the one-way function. Windows has never stored hashes in human-readable form, so there has never been a need to salt them.
Taken from Microsoft's own documentation: http://bit.ly/1juRmCT (Using Bitly because the link has parens and HN sometimes doesn't like that). Microsoft's argument boils down to this: Because they don't provide a GUI to view password hashes they're secure!
People gave LinkedIn and Adobe crap for their leaked password dumps not using a salt (or using reversible encryption!) and yet here we have MILLIONS of Windows installations all over the world doing the same damned thing. What's worse is that Active Directory also doesn't store password hashes using a salt. If your domain admin credentials ever get stolen the attacker is mere minutes away from cracking every damned password.
For giggles, here's a tool you can use to dump not only your saltless Windows password hashes but the actual passwords. This is because Microsoft also uses a reversible encryption scheme: http://blog.gentilkiwi.com/mimikatz
The passwords it displays (using the "sekurlsa" module) are from probing the process memory of LSASS.EXE to view cached credentials. So it will only display the plaintext credentials of currently logged in users.
However, this is actually an important exploit / factor to be aware of if you're considering installing software securely on a platform. Is it possible to blast through account credentials with a small method like this? I certainly wouldn't want to run any scripts on my machine if I knew that was possible on Linux, because merely being on the sudoers list would mean that my credentials are enough to damage my entire workstation. This doesn't even speak to the effect this would have if you got access to a sysadmin's account on a large network.
Consider for a moment all the tools and mechanisms in place to synchronize Active Directory passwords across domains, realms, and even 3rd party systems. Every one of those would completely break if you were to implement simple change such as the use of a salt.
That's why I've been saying for many years now that, "if you care about security do not use Windows." There's no mechanism available to actually make it secure because you can't change how it works internally. The best you can hope for is some obfuscation/hacks/tricks in regards to hardening (e.g. rename Administrator account, use entirely different credentials for administrative tasks, disable zillions of insecure defaults, etc). Then just hope you're never targeted.
If just one workstation is compromised an attacker can elevate their privileges to that of Domain Administrator with a few simple steps:
1. Install keylogger or password-dumping tool. 2. Force workstation to unjoin from the domain or cause some other problem that requires a Domain Admin to login to correct the issue. 3. Use credentials of Domain Admin to access a Domain Controller. 4. Dump the entire password database of Active Directory. 5. Crack the password database using some GPU instances in minutes.
After step #2 the attacker basically "owns" your network and can do whatever they want. You can mitigate it by joining Windows workstations using credentials that only have the power to perform a join but this is usually just a minor setback for an attacker as there's a plethora of tools and tricks they can take advantage of to escalate to Domain Admin.
For more information on how easy all this is: http://pentestmonkey.net/uncategorized/from-local-admin-to-d...
* The attacker can immediately view the user's password or just look at the saltless hashes (if they want).
Now let's compare that to, say, a Linux desktop (where similar zero days are extremely rare):
* Attacker will have to install a keylogger (usually by messing with the user's .profile, .bash_profile, .bashrc, etc) and wait for the user to spawn a new shell process where they actually enter their password at some point. This could be a long, long time or never at all if the user doesn't use the shell much. * Alternative: Because the shell option is unreliable (especially with more distros/businesses disabling LD_PRELOAD by default) the attacker will usually just run a program/script that prompts the user for their password. Unsophisticated users will probably just enter it but most IT professionals (the ones with privileged access) would immediately have a "WTF?" moment and that's very risky to an attacker.
I'd also like to mention that with things like SELinux and Apparmor it is very difficult for a userspace process to mess with the memory of another userspace process even when they're running as the same user. This makes it much more tricky to escalate privileges or obtain a user's password on a Linux desktop than Windows. Then there's the fact that on Linux there's a plethora of tools to detect and stop things like fiddling with LD_PRELOAD in user profiles.
...and if you don't like how it works you can actually change it! The source code for the kernel, the shells, the desktops, etc is there for you to do with as you please.
Two fatal flaws in your assumption.
1) Linux desktops in enterprise settings are incredibly rare. Linux servers? Way more common, but I can't remember any large corporation or enterprise using Linux desktops - it just doesn't happen.
2) Zero-day exploits DO happen to Linux. Would you be surprised if I told you:
"Vulnerabilities in the Linux kernel fixed in 2012 went unpatched for more than two years on average, more than twice as long as it took to fix unpatched flaws in current Windows OSes, according security firm Trustwave.
Zero-day flaws — software vulnerabilities for which no patch is available — in the Linux kernel that were patched last year took an average of 857 days to be closed, Trustwave found. In comparison zero-day flaws in current Windows OSes patched last year were fixed in 375 days."
http://www.zdnet.com/linux-trailed-windows-in-patching-zero-...
>>>> .and if you don't like how it works you can actually change it! The source code for the kernel, the shells, the desktops, etc is there for you to do with as you please.
I actually surprised you made this point, considering its been shown multiple times where malware and rootkits have been introduced into various Linux kernels. Just because something is open source, doesn't mean everybody is going to take the time to examine the source code and make sure its clean.
From 2009: http://www.darkreading.com/vulnerability/attack-sneaks-rootk...
"The attack attack exploits an oft-forgotten function in Linux versions 2.4 and above in order to quietly insert a rootkit into the operating system kernel as a way to hide malware processes, hijack system calls, and open remote backdoors into the machine, for instance"
"But Linux experts point out that the technique Lineberry is demonstrating at Black Hat indeed been has been deployed before with the so-called SuckIT rootkit, and as far back as the late 1990s with direct kernel-object modification (DKOM) rootkits]."
I'm quite surprised that LSASS.EXE is not protected in the same manner as AUDIODG.EXE [2]. Just goes to show how DRM protection is considered more important than system security.
[1] http://philosecurity.org/pubs/davidoff-clearmem-linux.pdf
[2] http://msdn.microsoft.com/en-us/library/windows/hardware/gg4...
Can you elaborate about what you mean with the pretty general term 'security'? Cause I've heard this before, and using both some linux distros and some windows versions I never felt particularly unsecure on any of them. Maybe that's a false feeling though - but how to check it? E.g. last time I checked, during normal operations, none of my boxes would have in- nor outbound connections to any peers that I didn't know of. And last time I ran a bunch of virus/malware scans on the windows boxes everything was fine as well. But if I understand you correctly your claim is this is not sufficient?
Now, how realistic a danger a HTTP MITM is it depends on your threat model; I don't think anyone's doing this on a large scale (other than governments in places like Iran and North Korea). But if you're worried about attackers targeting you specifically, then I think this is a valid threat vector.
MS tried to address this in earlier windows with digital signing of downloads (you get a warning if you try to run an unsigned executable, and a different warning identifying the publisher for a signed one, assuming the executable in question is marked as having been downloaded from the internet), and by integrating an app store into windows 8 (I think?). If done correctly, this would prevent this kind of attack - if you only ever run signed executables, and you trust the signers, you're safe. But the fact that even PuTTY, supposedly a piece of security software, is an unsigned download, suggests that this approach hasn't really spread through the windows software ecosystem yet. (The other approach that might work is extending UAC into some kind of full containerization approach, and isolating applications more fully from each other).
Now, a desktop system is always going to run a GUI, but a server has its attack surface reduced by not having a GUI, and most Windows servers have a GUI.
https://news.ycombinator.com/item?id=7338118
Also consider for a moment that everything is executable by default in Windows. Meaning, you download a binary from wherever, double-click on it, and it will execute.
Here's how that works on a Linux workstation: You download something, explicitly set the execute bit on the file, then you can double-click on it to execute (assuming it is statically compiled for the correct architecture).
The average user does not know or care how to set the execute bit on a downloaded file. This alone is a huge hurdle for attackers to overcome.
But then the other one remains, basically for any OS: if signature-based scanners aren't good enough, how do you properly check you are secure? Is something like connection logging sufficient?
The amount of hyperbole in this thread is amazing, but so far your comment represents the absolute peak of it.
I hope you're proud. It's quite an achievement.
When the OS enforces signature checking, you don't have to worry about whether it was downloaded over HTTP or who owned the domain name.
(btw, if you don't want to enable "allow all apps" on OSX, just rightclick (two finger click) and pick "open" from the context menu. it'll prompt for launch as opposed to just "no.")
Absolutely not. It puts Apple in total control over user's software. You have to place all of your trust in Apple that the binary you're running is actually build from the source code it is supposed to be.
Now, over in the free digital world, this problem is being addressed sanely. For example, NixOS and GNU Guix are tackling the issues of reproducible builds and package signing that can use a distributed web of trust. This way, no one has to trust a single company/entity or build machine. Debian is also after reproducible builds.
https://blog.torproject.org/blog/deterministic-builds-part-o...
https://blog.torproject.org/blog/deterministic-builds-part-t...
Well, yes, but your OS vendor is already in total control over its users' software.
The only difference this makes is that you don't have to trust anyone else.
Easier said than done, of course.
These controls are a great idea as long as the user has ultimate control. Apple does not seem committed to the idea of letting the user have control.
I can
cinst putty
and get what I need automatically.
Sure, I have to trust the maintainer, but you know, if more people used Chocolatey to install packages, more people might be able to ensure it's safe.
It's not bulletproof but it sure is better than searching the web for the right download.
Sure, they can move that particular download to https, but it doesn't install any confidence that they've thought through the rest of their flow. As far as I can tell, packages don't even need to be signed.
As a result, I'd not be able to trust anything they do.
This stuff is hard. And presumably we're doing this programming stuff because we're not afraid of hard problems.
One problem at a time - end users can't find the right links to download, so this solves that.
Now open some issues about the security stuff and let's get that patched up.
Telling people to not use Windows, or that "X is flawed so rather than fix it I'll avoid it" isn't moving anything anywhere. I'd rather get involved.
Yes, there is value in ensuring software is delivered without tampering direct from a trusted source. But the main problem people are dealing with is finding a trusted source for the install - one that actually delivers the software they wanted, without malware, without a confusing installer. Chocolatey solves the main problem pretty well. I can look at download counts, comments, and repos to verify what the installer is doing. There's an active forum that discusses problems or suggested improvements to packages.
It doesn't verify that there's no tampering along the way, but for most users that's an absolutely miniscule problem compared with the "Google / Click Link / Install Wrong Program and/or Malware" system.
As the saying goes, "Those who sacrifice freedom for security deserve neither."
At some point you have to trust someone. But who should you trust, and how much should you trust them?
Most people do not think about that and so we live with an Internet where privacy is almost impossible and most people just don't care about that.
However, there is also the risk that your host OS is compromised, in which case it may simply lie to you and do whatever it wants.
Yeah, pretty much. As soon as I say I trust X, then you know the first place to attack because I haven't secured it.
This means your options are limited, but if you believe you have a real adversary, then your adversary defines the scenario.
Option 1: Obtain source code, and secure a build environment. Review the source code. Build from source, and test the behavior of the built product. This approach incorporates some cognitive disonnance, particularly when building crypto software from source. The axiom "never roll your own crypto" brushes closely against building a tool like PuTTY from source. How do you know you did it right? Well... does anyone REALLY ever know?
Option 2: Pay through the nose, and carefully identify the entities you accept assistance from. Do your accomplices carry any conflicts of interest? This includes your ISP, and the open source project you've selected as the authors of your tools. Do you need to pay for professional class internet service, including pre-defined static TCP/IP routing across leased lines? Do you need to speak directly with the team that develops your software? Have you considered paying for a proprietary tool, with a service agreement? Is what your doing legal? Do you carry liability insurance, in case damages result from your actions? Do you own life insurance?
If you're confronting an opponent, is the scale of your opponent real, or imaginary? The manner in which you arm yourself for the confrontation will be priced accordingly.
...but the short answer is: obtaining hashes over SSL from a source with a certificate that can be validated by a "trust-worthy" certificate authority is "probably" okay for most ordinary people, who aren't confronting state-sponsored adversaries.
The vast majority of 'attacks' on Windows are based on exploiting user trust: phishing, malicious binaries, and so on. Suggesting Linux as a fix to that is nonsensical, unless you expect every software under the sun to be both included and properly verified (reality: it's not).
[1] http://www.sublimetext.com/ -> http://c758482.r82.cf2.rackcdn.com/sublime_text_3_build_3059...
Since I want as little software installed on the host as possible, I'm going to have to start a VM on something like Azure (easiest) with Visual Studio, and build my own copies of these tools if possible. The culture of building stuff on Windows is fairly weak, so I imagine I'll run into all sorts of issues.
It's pretty embarrassing that Windows doesn't ship with a lightweight way of creating "VMs" to increase security. Something like Sandboxie would be a welcome piece of OS functionality.
The JS crypto comment is off-base. The discussion about JS crypto is that it's pointless because it's only as strong as TLS - it doesn't provide anything else, and it's very easy to get it wrong and get more damaged (due to ease of XSS and whatnot). Sandboxed execution is a fantastic thing, and even MS tried that with .NET and it's million code-access-security policies. And now everyone does that with Android/Windows Store style permissions (although not as fine grained).
How was this, that some people broke into a signature authority and stole master-keys -- so a huge number of keys where compromised. I don't know, if that thing was repaired yet. Also there exist many authorities that give keys to people without the simplest identity check. Such keys are a security risk of its own.
I also don't know, how good (or bad) the key withdrawal mechanism is working currently. I remember darkly (I am not current in these things) that there existed some problems with existing browsers, infrastructure and so on ...
And even, when those things would work fine ... as much I know, there exist holes in the implementation, depending which algo combination is used.
So there are so many attack vectors, that even in the best case (https works fine and you have a domain that belongs to the correct author ... and you have checksums ... and you check, if your browser tells you, that the certificate is perfect (who in the internet age cares, when the browser says that the certificate has some problem??) ...) there seems to be no security in the internet age ....
(And I am not even speaking or thinking about governments spying on us all)
I'd hardly call that a bulletproof argument.
OK so we can also boot Linux in a browser, if you stick with it apparently you can do just about anything in JavaScript if you're willing to spend the CPU cycles to do it.
Why? ChromeBook as an example, why move everything into the browser so that the OS is minimized or even removed, you're still going to face the same software problems.
The OS's model is based off of the user being the unit of security. If a user runs a piece of software, that software can interact with all files owned by the user. It can make web requests to anything.
The browser's model has the unit as the webpage, not the user. Each webpage is sandboxed from others. If one webpage is malicious, in theory it cannot modify users files or even other webpages.
The difference in model makes a malicious webpage significantly less scary than a malicious program.
Your example, of running your whole OS in the browser, is unrealistic; in reality you'll be running each piece of the OS in a different isolated tab.
This model can work since the web was built for each site to be independent and self-contained... We've already gone too far down the rabbit-hole of native programs being extremely powerful to easily fix that.
The OS might not be lost though. You can run scary software in a VM. You can run each program in a separate chroot. Perhaps soon you could just spin up an lxc (with docker perhaps) for each different program you want to run. These methods of running software all basically transform the OS into using the browser's model.
It's also worth mentioning that the browser model has inherent security flaws for as long as it persists the executable on external servers; you have to find a trusted channel to access the data everytime whereas the program only has to be verified once after downloading.
The user loses control, the user loses.
>> This model can work since the web was built for each site to be independent and self-contained...
https://developer.chrome.com/extensions/samples "Content Script Cross-Domain XMLHttpRequest Example"
>> whereas the program only has to be verified once after downloading.
Opening the door to hackers who find ways to infiltrate that program _after_ that check has been done.
Right?
Sandboxing applications would be a good start. That way you don't need to trust application developers.
e.g. http://en.wikipedia.org/wiki/PuTTY points to Putty's official website: http://www.chiark.greenend.org.uk/~sgtatham/putty
Putty is open source (MIT), one could build it from source and even audit the code. Nevertheless, thanks for pointing it out.
Another slam against squatters as usual. I really really wish people would stop with that already.
Whoever Denis Bider is he has no obligation to even put up links to putty. He could sell the domain name maybe even to these people who don't appear to be "using" (by the HN and generally acceptable definition of "using"). In other words http://putty.com/
For the last time. There is no requirement to use a domain name and there never has been a requirement to use a domain name. And there are many people and companies who just sit on names and don't want to sell (because they don't need the money).
Talk to google about duck.com and see if you can buy it. You won't be able to.
Anyway he could put up a webpage as his personal blog or any number of things.
Just because you happen to have a product using a particular name does't mean you own that name in every tld (.com .net .org .info .us .biz and so on).
.org isn't even .com nor as desirable except perhaps for non profits.
This came about when the domain for codehaus.com expired and it transferred over to a parked site that responded to all requests with advertising. I ended up with a bunch of HTML files where I was expecting library jars. In this case it was merely annoying and caused some tests and builds to fail. If they had instead been providing malicious code that almost looked like legit libraries it could have gone un-noticed for a long time.
[0]: http://security.stackexchange.com/questions/52357/what-is-going-on-with-my-download-of-the-recent-apple-security-updateYes, that may often be hard, or nearly impossible. WOT sadly often only works for people you can personally verify anyway.
(With HTTPS, you better wish the author chose a reputable and more expensive certificate authority which can be trusted not to give certificates without proper proof of address ownership. Otherwise, verifying the website certificate may be as hard has verifying personal keys.)
> Let’s say you have a brand-new Windows laptop and you’re just oh, so happy.
It's a hypothetical situation (but one which windows users will likely encounter if they want to use ssh)
There's binary OpenSSH releases for Windows, but they're all hosted on sites that don't do HTTPS. It seems like all Windows free software has a general lack of following security best practices when releasing or mirroring software.
Downloading *Putty* Safely Is Nearly Impossible.Step 18 is probably the inevitable step that follows thinking about something too much.
Those who give up privacy expecting to gain download safety will lose both.
Even if it is open source, am I expected to pore over thousands of lines of code to verify that it hasn't been compromised?