tag:blogger.com,1999:blog-7347279.comments2023-08-26T05:04:33.009-04:00anti-virus rantskurt wismerhttp://www.blogger.com/profile/03810635947269551517noreply@blogger.comBlogger783125tag:blogger.com,1999:blog-7347279.post-60062504941263192842017-12-15T05:30:35.099-05:002017-12-15T05:30:35.099-05:00This comment has been removed by a blog administrator.Marcelhttp://www.ceneo.pl/noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-19420800604940425802015-10-07T15:16:34.611-04:002015-10-07T15:16:34.611-04:00This is the product marketing style of Bill Gardne...This is the product marketing style of Bill Gardner, snake oil salesman #1Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-51621540431792500882015-09-02T07:31:40.091-04:002015-09-02T07:31:40.091-04:00Kurt, I have no way of knowing whether the two ano...Kurt, I have no way of knowing whether the two anonymous sources actually exist. Even if they do, they could have still made up the story in order to harm a former employer that they might have left not on the best of terms.<br /><br />It doesn't really matter. What matter is that, as described, the attack simply isn't going to work and if these sources were real and have real, hard information, why didn't they share any hard technical details?! I mean, one that an expert would find believable? It seems that they (or just Reuters) are playing on the general public's lack of understanding of how AV products actually work.<br /><br />I have no problem with your argument that the AV industry needs better quality control. I just have a problem with Reuters' bullshit story.<br /><br />The FireEye story you are referring to is completely different. A rogue employee at the company decided to make some money on the side by selling a piece of malware he had designed. While unethical and otherwise despicable, I have absolutely no problem believing that. I do have a huge problem believing Reuters' story.<br /><br /><br />Anonymous, please read again what I have written and try to understand it. You can reverse-engineer a competing product and see how it works - but you cannot know how a competing AV company selects malware identification data, unless you work there and are familiar with the process. You certainly can modify a non-malicious file to me misidentified as some known malware by a given product. But that certainly won't be a legitimate file any longer, and detecting it (while being a misidentification) would not be a false positive. You can HOPE that you will luck out and somebody's AV product will implement detection of it by picking parts which are also present in the original, unmodified file, but you cannot be sure that it will happen. That's why you can attack the whole industry this way (and will almost certainly "luck out" with some products), but you cannot attack a particular product this way and make sure that it causes a false positive.<br /><br />Oh, and BTW, while the creation of malware detection and identification entries is automated to a large degree, it is not fully automatic - there is usually a human somewhere in the loop. At the same time, every self-respecting AV company DOES conduct false positive testing in-house (and those ARE automatic), so if a false positive wasn't caught it is, to a large degree, a failure of that AV company's internal quality control procedures.<br /><br />If the Reuters story had claimed that Kaspersky had attacked the whole AV industry this way, it would be stupid and difficult to believe claim - but at least it would have been technically possible; I'd just require some hard evidence (besides relying on dubious anonymous sources) that it was actually done. As it is now, the attack, as they have described it, is simply unreallistic.Vesshttps://www.blogger.com/profile/09226866181634905270noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-35830616710037609492015-09-02T04:23:21.458-04:002015-09-02T04:23:21.458-04:00Sorry Vess, but the exploit method described my Re...Sorry Vess, but the exploit method described my Reuters can easily work with any vendor who does fully automated signatures, which would be any vendor who gets 50000-100000 new samples per day.<br /><br />Like you said, a static malware detection works roughly by looking a some parts of the file that are enough to ensure it's a known malicious. Might be a checksum, or for smaller blocks might be a comparison. Now, if you reverse engineer that a real malware file gets detected by the by the arget by looking at certain specific blocks, what if you change those small blocks to contain the same bytes of a Steam core file, and upload that file to Virustotal? With any luck, the automated detection generator system will correctly mark the file as malicious due to its full contents, but will make a new detection using the same exact offsets as before. Now, when that detection gets released, it will detect your modified malware, but it also will detect the Steam core file!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-47601161861381494702015-09-01T18:45:34.194-04:002015-09-01T18:45:34.194-04:00i appreciate your candor, vess. let me ask you som...i appreciate your candor, vess. let me ask you something, though - you believe the story is bullshit, but how far does the bullshit extend? are the anonymous sources real or made up? if they're real people who actually contacted the journalist, are they really ex-employees or are their credentials forged? <br /><br />i think since there's already recent news about an intern at another company being charged with malware-related crimes that my conclusion about a quality problem still stands, but if the anonymous sources here aren't actual ex-employees then they can't back up that conclusion. kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-46605247836852599922015-09-01T18:06:51.291-04:002015-09-01T18:06:51.291-04:00OK, politics, ethics and other bullshit aside, me ...OK, politics, ethics and other bullshit aside, me being a techie, I started thinking - can one do something like this in principle? Can you force a particular AV product to cause a false positive? Not by using the method described in Reuters' story, of course - that won't work. But can it be done by other means?<br /><br />I discussed some ideas with various people and, sadly, the conclusion is that yes, it is technically possible.<br /><br />As you probably know, contrary to popular belief, scanners stopped relying exclusively on "signatures" (i.e., scan strings) mode than two decades ago. Nowadays many other, more precise and reliable methods are used. One of them involves computing some sort of checksum of the non-variable part of the malware (or part of it, if the malware is large).<br /><br />Now, for performance reasons, nobody is really using a cryptographically strong hash function for the checksum. Some use plain CRC-32, some use proprietary functions - but they are all simple and fast; not cryptographically strong. Which means that for a cryptographer, it should be relatively easy to find collisions for them - i.e., two different pieces of data that both have the same checksum. (This is feasible even for MD5, let alone for something as trivial as CRC-32.)<br /><br />So, the attack goes like this. You reverse-engineer the AV product and determine what kind of checksum is used and for what kind of objects (one and the same scanner often uses different identification methods for different kinds of malware). Let's say that you find out that for small, self-contained malware (i.e., not a parasitic virus) that contains no variable areas, the scanner identifies it by computing a CRC-32 of the first 512 bytes after the entry point.<br /><br />So, you take some relatively small legitimate and widely used file and compute this checksum of the first 512 bytes after its entry point. Then you write some malware (small, self-contained, no variable areas) and make sure that it has the same length and the same checksum of the first 512 bytes after the entry point. You send this (clearly malicious) file to the producer of the product you want to attack. They implement detection the way they usually do for this kind of malware and - blam! - they will also detect the legitimate file.<br /><br />Of course, you'd have to hope that their in-house false positive testing doesn't pick up this before the new entry gets distributed to the world.Vesshttps://www.blogger.com/profile/09226866181634905270noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-44151583753875618382015-09-01T18:05:24.312-04:002015-09-01T18:05:24.312-04:00This story was started by Reuters. As far as I am ...This story was started by Reuters. As far as I am concerned, it is clearly bullshit. In fact, I suspect that it is an intentional smear campaign, a kind of psy-op conducted against Kaspersky. Remember that several government intelligence agencies have a reason to be pissed off at Kaspersky.<br /><br />Reuters have recently doubled-down on that story, using even less trustworthy means, by claiming that "e-mails have surfaced that support it". Turns out, these e-mails support nothing of the sort except that Kaspersky was pissed off by other companies reverse-engineering his product and staling his intellectual property. (That much is indeed true; I remember when a Chinese AV producer was stealing his whole database; this prompted us all - the AV producers - to introduce "fake" entries in our databases. That is, entries that are not listed when the scanner is asked to list all the viruses it detects and which detect no real malware and no real legitimate file but specially constructed files of our own that are kept secret. If the competition suddenly starts detecting these files of ours, this is an indication that they are stealing our database entries.)<br /><br />Now, the way Reuters is telling the story, this thing is impossible to conduct in a targeted way. Yes, you can take a legitimate file, modify it so that several scanners start detecting it as malware and upload it to VirusTotal. It will end up being sent to the whole industry, many producers won't bother analyzing it since "several other scanners are already deteting it" and will implement detection of it witout thinking. Or at least you can hope so. And you can also hope that when they implement detetion, they will be stupid enough to pick identification data from the legitimate part of the file, causing false posities on the original, unmodified file.<br /><br />Yes, this can be done and has been done - against the AV industry as a whole. And several AV producers did fall for it (including Kaspersky, the irony). What you cannot do, is ensure that (by using this tactic), a particular product will cause false positives. You simply cannot control which part of the file will be picked for identification purposes by the producer. You can attack the industry as a whole - and many products will fall for it - but you cannot attack a particular competitor.<br /><br />The other "clearly bullshit" part of the story was that, allegedly, Kaspersky did that to punish competitors who were stealing from him. And one of these competitors was, allegedly, Microsoft?! We aren't talking about a two-bit no-name unreachable Chinese schmuck here - we are talking about one of the largest companies around that can be sued for hundreds of millions of dollars if they are caught stealing - and they were supposed to have stolen Kaspersky's detection entries?! Come on.Vesshttps://www.blogger.com/profile/09226866181634905270noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-12500651724906194862014-06-21T12:47:31.562-04:002014-06-21T12:47:31.562-04:00Malware can do many many things that could be leve...Malware can do many many things that could be leveraged on a microVM. For example, you could spawn DDOS, Generate Bitcoint or Consume CPU, thats just to start. The fact is, you're technology is cool but there's no silver bullet... I like the blog post, and it IS correct.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-14645334975928148242014-04-04T13:06:21.706-04:002014-04-04T13:06:21.706-04:00i know that converting to a GOTO-less form can hav...i know that converting to a GOTO-less form can have bad results. i included an example, but i guess it wasn't the worst example i could have done. i could have replaced each GOTO with a copy of the clean-up code and a RETURN statement if i wanted to maximize the amount of duplicated code rather than the amount of nesting.<br /><br />i absolutely agree that it's better start with structural approaches in the first place. <br /><br />what i'm concerned about is that many people aren't even trying because the wide acceptance of GOTO gives people a way to avoid actually becoming proficient at structured programming, and that lack of proficiency in turn is leading to myths about structured programming that give people an incentive to accept and continue the bad habit of unstructured programming. <br /><br />and i'm concerned that that is negatively impacting security because many of the people in charge of writing important security-related code are amongst those who aren't trying. i've looked at 4 different crypto libraries and they're all filled with GOTO.kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-56977794451256093682014-04-04T11:37:44.466-04:002014-04-04T11:37:44.466-04:00There is a theorem that if a language has some bas...There is a theorem that if a language has some basic flow control constructs (if/then/else, while/do, begin/end) then <i>any</i> algorithm can be programmed in that language without using goto. The proof of this theorem is constructive - i.e., it show how to take an arbitrary flowchart and re-arrange it so that it uses only the above constructs and no gotos.<br /><br />But that's just theory. In practice, if the algorithm is designed badly, converting it to a form that doesn't use goto can result in a program which is much more inefficient (has repeated blocks of code) and difficult to read (I kid you not).<br /><br />One should use the structural approach when designing algorithms in the first place - not convert them artificially into a goto-free form after the fact.Vessnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-90302204777209308712014-03-11T23:34:15.754-04:002014-03-11T23:34:15.754-04:00@Matt Boney:
i do in fact mean literally the keywo...@Matt Boney:<br />i do in fact mean literally the keyword GOTO. i'm aware that RETURN and BREAK are related to GOTO, but they are much more constrained than GOTO. for example, neither RETURN nor BREAK can jump to a point in the code preceding themselves. the constraints on RETURN and BREAK reduce the amount of complexity using them can add.<br /><br />while i'd certainly agree that skipping important behaviour is bad, that is something that can be done with all kinds of statements. even getting the conditional expression in an IF statement wrong can lead to that. kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-73452845059678017512014-03-11T20:59:17.020-04:002014-03-11T20:59:17.020-04:00Do you mean goto in the generic sense of an uncond...Do you mean goto in the generic sense of an unconditional jump or literally the keyword goto?<br /><br />do<br />{<br /> int rv = something();<br /> if (!rv)<br /> {<br /> /* GOTO */<br /> break;<br /> }<br /> something_else();<br />} while(0)<br /><br />int some_function()<br />{<br /> int rv = something();<br /> if (!rv)<br /> {<br /> /* effectively a goto */<br /> return 0;<br /> }<br /> <br /> return something_important();<br />}<br /><br />Harping on the goto keyword is pretty pointless, really the culpret is control flow semantics that skip very important behavior.Anonymoushttps://www.blogger.com/profile/02989861723418043330noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-21774707000252950812014-02-26T01:08:48.934-05:002014-02-26T01:08:48.934-05:00@Phil:
"There is nothing wrong with using &qu...@Phil:<br />"There is nothing wrong with using "goto" in C code, as long as it's used properly."<br /><br />please refer to the final paragraph of the post. alternatively, i could rephrase this claim as "there's nothing wrong with goto as long as you use common sense" and then opine about how uncommon common sense is.<br /><br />actually, refer to the discussion about the reduction in the possibility space for control flow. that is a complexity reduction, even when measured against code where goto is used sensibly. less complex code is easier to ensure is correct, while more complex code is easier to get wrong. as such i axiomatically reject the notion that there is "nothing" wrong with using goto.<br /><br />as for the example of the same error happening with a double early return, yes that's true. not once in my post did i say that the use of goto was what caused the bug that Apple fixed. instead it was the bug that Apple fixed that highlighted a deeper (but not necessarily related) problem.<br /><br />as for goto not being used mindlessly, look at the code again. specifically, look at the final goto in the problem function. do you see any code between that goto and the label it references? no, there is none, because goto WAS being used mindlessly.kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-29565447595096745512014-02-25T20:03:37.072-05:002014-02-25T20:03:37.072-05:00Err... that last line should be "mostly harmf...Err... that last line should be "mostly harmful" not "mostly harmless." Philhttps://www.blogger.com/profile/01555269677231761660noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-9113835314690459022014-02-25T20:02:26.286-05:002014-02-25T20:02:26.286-05:00This strikes me as an incredibly dogmatic post. Th...This strikes me as an incredibly dogmatic post. There is nothing wrong with using "goto" in C code, as long as it's used properly. In this case, it looks like it was used for cleanup code, which is a fairly standard practice in C programming. The exact same error could have occurred if the author had written: <br /><br /><br />if ((err = foo()) != 0)<br /> return err;<br /> return err;<br /><br /><br />More or less the exact same error without the gotos. I only briefly skimmed the file, and in each case it looked like it was used to jump to common cleanup code. IMO this is much safer than the following: <br /><br /><br />if (err == ERROR1) {<br /> free(buf); <br /> return err;<br />}<br />/* Do stuff */<br />if (err == ERROR2) {<br /> free(buf); <br /> deleteBaz(&myBaz);<br />}<br />/* ... */<br />if (err == ERRORN) {<br /> free(buf)<br /> deleteBaz(&myBaz);<br /> /* ... */<br /> deleteBar(&myBar);<br />}<br /><br />Gotos were not used to jump around mindlessly in a function; this wasn't spaghetti code by any stretch of the imagination. Yes, goto is mostly harmless, but it can be used safely, and in some cases it's the best option.Philhttps://www.blogger.com/profile/01555269677231761660noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-4264332723907053502013-08-08T19:30:12.304-04:002013-08-08T19:30:12.304-04:00This is why I work on my own malware scanner. Tak...This is why I work on my own malware scanner. Take that as you will.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-70091539453395036632013-05-30T12:33:19.169-04:002013-05-30T12:33:19.169-04:00@Anonymous:
maybe you should look more closely at ...@Anonymous:<br />maybe you should look more closely at Tal's comment. he agreed that it won't defeat all malware, therefore remediation <b>WILL</b> still be necessary at least some of the time.kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-17387566831892299202013-05-30T12:14:26.691-04:002013-05-30T12:14:26.691-04:00I'm in agreement with Tal. You are confused i...I'm in agreement with Tal. You are confused in how the technology works and are making inaccurate conclusions. There is no need to remediate a malware infection if it only exists in memory (a VM). It's akin to why EC2 maintains multi-tenancy.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-78098042035274910922013-05-30T10:48:05.714-04:002013-05-30T10:48:05.714-04:00@Anonymous:
"It's obvious that these conc...@Anonymous:<br />"It's obvious that these conclusions are derived without a proper demonstration and understanding of the technology."<br /><br />the conclusions in the blog post don't depend on how the technology is implemented. it is about a) how bromium presents their technology, and b) the theoretical limitations of isolation based techniques.<br /><br />it doesn't matter how clever they are, they can't exceed theoretical limitations.kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-72522332689663406772013-05-30T10:30:21.459-04:002013-05-30T10:30:21.459-04:00It's obvious that these conclusions are derive...It's obvious that these conclusions are derived without a proper demonstration and understanding of the technology. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-56780273958500765472013-05-27T20:14:50.437-04:002013-05-27T20:14:50.437-04:00@Anonymous:
i don't think i'd be so quick ...@Anonymous:<br />i don't think i'd be so quick to draw conclusions about the user experience/security trade-off without actually using it first.<br /><br />unless you have and you're speaking from experience - in which case, thanks for the info.kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-53157323596607627472013-05-27T19:29:37.510-04:002013-05-27T19:29:37.510-04:00Tal, when the security community came up with DEP,...Tal, when the security community came up with DEP, it was a huge step forward reducing attack surfaces until the malware folks overcame it. ASLR was another huge step forward to reduce attack surfaces until that was subverted too. I am sure this micro virtualization stuff is yet another iteration of the same. <br /><br />The scary bit in Bromium's case here is that you depend on exception policies and any policy based security mechanism is either too annoying and prevents getting useful work getting done causing the policies to be relaxes to an extent where the attack surface goes back up again and you get attacked by malware.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-43443902178230320842013-05-27T19:02:54.199-04:002013-05-27T19:02:54.199-04:00"At no point do we ever claim we will block 1..."<b>At no point do we ever claim we will block 100% of all malware, ever.</b>"<br /><br />except you actually did. the malware set is a proper subset of the set of all attacks. by claiming that you defeat all attacks you are also saying that you defeat all malware.<br /><br />you want me to "<b>stop nitpicking and focus on the big picture</b>" but that's not how i work. i'm detail oriented and i focus on the way things can fail. that is part of the security mindset. it is necessary in order to be able to plan for and hopefully mitigate those potential failures.<br /><br />you folks certainly aren't facilitating that thought process so somebody has to do it, and if it means tarnishing the rosy image of your "big picture" then so be it. rose-coloured glasses don't keep things safe.<br /><br />(for the record, i read what you gave me (and more). that's how i found what i found.)kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.comtag:blogger.com,1999:blog-7347279.post-30289141011542471632013-05-27T17:26:06.368-04:002013-05-27T17:26:06.368-04:00It seems to me that regardless of what we do, you&...It seems to me that regardless of what we do, you'll just scream back "snake oil".<br /><br />I actually gave you a reading syllabus that included two whitepapers, a blog, and a Q&A. We actually quote Turin's Halting Problem as one of the primary catalysts for the creation of our technology.<br /><br />In our white papers, we specifically say that nothing is impervious to all attacks. You are confusing two statements:<br /><br />1. We block 100% of known malware.<br />2. We exponentially reduce the endpoint attack surface (by our math, approximately 10^4).<br /><br />At no point do we ever claim we will block 100% of all malware, ever. I agree with you, that would be a preposterous statement.<br /><br />My advice to you is to stop nitpicking and focus on the big picture. Our micro-virtualization is a huge step forward in secure systems architecture, and it directly integrates with existing operating systems and endpoints, thus immediately reducing the attack surface of any company which adopts it. That's a fact, not snake oil.<br /><br />-TalAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7347279.post-37598262510992103972013-05-22T15:50:32.863-04:002013-05-22T15:50:32.863-04:00oh for crying out loud. i'm not comparing brom...oh for crying out loud. i'm not comparing bromium to sandboxie. i'm simply pointing out that i've seen copy-on-write before in other types of products.<br /><br />you folks may have been the first to apply copy-on-write to the particular kind of virtualization you're doing, but the general concept predates you.<br /><br />as for VMs, i think we're going to have to agree to disagree on what constitutes a '<i>virtual</i>' <b>machine</b>.<br /><br />and thanks for the links. i will get to them in good time.kurt wismerhttps://www.blogger.com/profile/03810635947269551517noreply@blogger.com