The SHA256 of that file is exactly that of Firefox Setup Stub 35.0.1 (Win32), so of course Authenticode checks out.
I'm not 100% sure why some people thought it was a malicious file, but the comments on Virustotal mention [1] which, for me, redirects to the legitimate [2] but a comment seems to link it with [3] which is a completely different file. Perhaps the redirection is randomized so people got confused?
[1] hxxp://files.dodo-number-1.pw/p/MCLkP8Dzc3nUWJrG9fwGLA,1442015273/zte%20mf631%20firmware%20downlo_10924_i57945825_il345.exe (replace hxxp with http)
Their conclusion is simply that "the major part has been fixed" in MS12-024, and that you should be careful if you write a self-extracting installer. No big deal.
I'm not talking about a "trusting trust" attack, which is difficult to pull off and requires special compiler knowledge because it needs to survive bootstrapping.
Here the attacker just needs to patch a binary once and he already has complete control over the machine, so he has an infinite number of options: from simply manually replacing the binary file before it's uploaded to the website, to replacing gcc with a script that patches the source code before calling the original gcc.
Yes, the number of reported vulnerabilities isn't a good metric to judge the security of a project. It often means that few people bothered to look, and that when developers fixed a bug they didn't try to find out whether it was exploitable.
The latter is supported by the fact that changelog entries don't discriminate between security bugs and normal bugs, and by the fact that no vulnerability was ever reported by the developers themselves.
More worryingly, in all instances where a vulnerability was reported, the CVE vulnerability was filed specifically because the reporters were security researchers. This means that when a normal user reported a crash bug, no vulnerability was EVER filed. How likely do you think it is that none of those crashes could possibly be turned into an exploit? There are 95 instances of "Some bugs were fixed" in the changelog.
Not on Windows, at least. The properties dialog can tell you it uses HFS+ if you ask for it, but it's too late because the HFS+ code has already been executed.
Thank you. To be clear, I don't mean that as a criticism of the developers, who as the parent points out do very useful work and do it for free. But I feel that it's important to have an objective look at the current shortcomings in the state of 7-zip security, both in order to understand what needs to be done to fix it, and in order to warn current users until those issues are fixed.
7-zip is a widely popular basic utility, like a web browser. A flaw in 7-zip is very serious, because as I pointed out elsewhere simply opening a .zip file will allow an attacker to exploit it. And while there is a strong security culture among web browser developers, 7-zip doesn't seem to have that culture (yet).
There is certainly a massive budget and manpower difference, but a lack of mention of security fixes in the changelog and a lack of hashes isn't a manpower issue, it's a culture issue.
As a side note, compromise of a developer's machine is a big deal in my opinion: it could be easy for a criminal entity to slip in a tiny change in a large patch that introduces a vulnerability; and depending on how builds are performed, a criminal could patch the final .exe with no visible change to the source code. These are tailored attacks, but for a very widely distributed program it would easily be worth the criminal's time.
Can you give me pointers about authenticode flaws? After a quick search the two issues I found were with MD5 collisions (solution: the signer should never emit MD5 certificates) and certificate padding (solution: the user should set a registry key to enable verification of padding; search for "EnableCertPaddingCheck").
I just did some testing and it's even worse than that: 7-zip completely ignores the file extension and snoops the file format based on the file contents only.
So simply opening a malicious ".zip" file on Windows could trigger the HFS+ vulnerability. Using 7-zip to open any file means you have a HUGE attack surface.
EDIT: One simple way to mitigate this issue would be to just throw a confirmation prompt if the file extension matches a known format but 7-zip is about to run a decoder for a different format.
I am appalled at how unseriously 7-zip seems to take security.
The changelog only says "Some bugs were fixed", with no mention that there are serious security flaws. The homepage doesn't mention any vulnerability.
The installer is not signed, downloads are over HTTP only, and there is no hash available neither on the homepage or on the forum announcement linked from the homepage (the latter is served over HTTPS so it would be a reasonable option); thankfully you can dig around Sourceforge downloads to find a SHA-1 automatically generated by Sourceforge. So I can personally verify the integrity of downloads, assuming Sourceforge can still be trusted, but 99% of users won't do this, and more worryingly it's a strong signal that the developers may not understand or value security very much: you have to wonder if maybe they're not themselves downloading unsigned software over HTTP all the time.
There is some very shady SEO going on here. The French translation link goes to a Wordpress blog with a very bad translation of the introduction. The root of the translation website is a completely unrelated Dutch used car website.
Other pages on the translation blog follow the same pattern: an old webpage (this HN entry is from 2009, but other pages go back to 2000) is edited years later to link back to a bad translation in some random language.
This is very far from my area of expertise, so I'm curious to know if this is well-known, and if those pages were hacked or if this was inserted by the owner himself.
EDIT: This is fascinating. I'm finding dozens of similar blogs, with links spanning at least a thousand hosts, which I'm assuming were hacked. This is a big network, with sophisticated wording designed to look as innocent as possible.
I just downloaded the dataset, and color is such a powerful feature that training a random forest on images downsampled to a single pixel results in 95% and 98% accuracies! (for the 4-category and 6-category versions, respectively)
And you can easily exceed 99.5% by adding more features to the forest, which is far above their DBN accuracy.
I have no idea how they were able to get an accuracy as low as 69% when they evaluated random forests.
The grant is for the DAL project [1], which presumably fits the "ground-breaking, high-risk" label. In such a project, some tasks will be high-risk, some tasks will be low-risk. Quantifying the branch predictor of current processors may be a comparatively easy task, but that doesn't mean it's trivial, useless or outside the scope of the project, which is to improve sequential performance of microarchitectures. Knowing that real-world processors are performing just as well as previous academic research is helpful, because it suggests that there is no difficulty or unrealistic assumption that prevented manufacturers from doing so. Conveying that knowledge to the compiler and interpreter community is important too.
> the one other researchers (which I respect much more) discovered in 2006
You seem to be blissfully unaware that they're in fact the same researchers: André Seznec is a co-author of the paper.
This paper is valuable in pointing out that ITTAGE branch prediction performance is a very good predictor of Haswell performance. Because the Haswell algorithm is secret, that should be very helpful to developers who still have to care about branch prediction.
Interpreter developers shouldn't ignore pre-Haswell chips just yet, but if you were to, say, develop a new language your design decisions should be guided by where the puck will be rather than where it used to be.
There are no absolute values in the summands, so in your example pairs of consecutive terms sum to 0 when you choose b = 2.
The theorem seems entirely correct to me. You can prove it with these sub-steps:
(1) the set of all j + a_j is the set of nonnegative integers minus a finite number of gaps
(2) thus for large enough n you can express \sum_{j=1}^n (j + a_j) as a quadratic function of n, plus a residual term e(n) of magnitude at most 1007^2/2
(3) more precisely, \sum_{j=m+1}^n a_j = g (n-m) + e(n) - e(m) where g is the number of gaps in (1)
What the article doesn't state clearly is that this assumes the strong exponential time hypothesis: it assumes that SAT cannot be solved in time 1.9999^n -- in other words that it's impossible to do better than the brute-force algorithm, which has complexity 2^n (up to polynomial factors). That's a very strong assumption.
I see the article climbing back up the front page, and I want to make it abundantly clear that I don't believe that there is necessarily a causal relation from breastfeeding vs formula to IQ.
I could control for demographic factors, but not for other major important factors in a child's development -- parental IQ or views regarding parenting are huge factors in a child's IQ, and they may also influence the decision of whether or not to breastfeed. If parenting books unanimously decided that formula was bad, then parents who cared enough about their children to read them and follow their advice would be more likely to breastfeed and you would see a positive correlation with IQ, even if formula was completely equivalent to breastfeeding.
So while there is a clear correlation after controlling for demographic, there is not necessarily a causation. My formulation really wasn't meant to imply causation, but rather the handling of unknown data (I grouped unknown-status children together with breastfed children). When talking about correlation, it's not meaningful to make a distinction between IQ impairment and IQ gain.
The contest was hosted on TopCoder. The name of the organization who provided the data and funded it is not public, but I'm told it will be made public at some point.
I found a big improvement to my model just after the contest was over, so I made a proposal to develop the improved model and do some more in-depth analysis. I'm currently waiting for their reply!
If they accept I'll have an opportunity to look deeper -- it's one thing to develop an efficient model, but fully exploiting it in order to gain a better understanding of the data takes some work. A limitation of these contests is that you're rewarded for producing a very efficient model, but there is very little emphasis on analysis of your model once you built it. I think it's a shame, because the person who built the model is often in the best position to have a good intuition of both the dataset and why the model had to be built that way.
I've been considering opening a blog, but I haven't found time to do so yet.
Briefly, the purpose of the contest wasn't to understand the effect of breastfeeding, but to understand how important normal child growth is to mental development. They included several scenarios: with all data available, with demographic data removed, and with demographic data and growth curves removed. Unfortunately, IQ is so overwhemingly affected by demographic that the scenarios without demographic data devolved into a game of extracting all the demographic data that was leaked by non-demographic variables. And when demographic data is available, more than 90% of the variance extracted by the model comes from demographic data rather than biological measurements!
It's really disheartening to think that depending on the social setting you come from, you start with an IQ of 85 or 115 -- at age 7...
I compared my dataset and their data, and it turns out that even in Brazil there is significant correlation between mother education and breastfeeding, barely less so than on the dataset I have. So you should probably disregard my edit in the above post: accounting for confounders could be important in both cases.
I'm not 100% sure why some people thought it was a malicious file, but the comments on Virustotal mention [1] which, for me, redirects to the legitimate [2] but a comment seems to link it with [3] which is a completely different file. Perhaps the redirection is randomized so people got confused?
[1] hxxp://files.dodo-number-1.pw/p/MCLkP8Dzc3nUWJrG9fwGLA,1442015273/zte%20mf631%20firmware%20downlo_10924_i57945825_il345.exe (replace hxxp with http)
[2] https://download-installer.cdn.mozilla.net/pub/firefox/relea...
[3] https://www.virustotal.com/es/file/e6821e86a9d3fb693b32077e6...