再保险:作业恶意软件

星期一,2018-08-13在-0600年十四10,Kurt Seifried写道:> Mon, 8月13日,2018年在2:01点,帕斯卡莫尼耶> < pmeunier@cerias.purdue.edu > >中写道:> > >在星期一,2018-08-13在-0500年14:44,耶利哥写道:> > >在星期一,2018年8月13日,Kurt Seifried写道:> > > > > >:根据名称解析和名称空间如何如何管理> > > > > > >(或> > >:不是),它可以被攻击在某些情况下,通过自动> > > > > >:依存关系解析器。再一次,如果有恶意代码> > >:分布式和使用有一些具体的原因我们不> > >想> > > >告诉> > >:人,宁愿忽略它呢?> > > > > > >快速的答案是“是的”,体积。试图追踪任何网站> > >分发恶意软件将是广泛的,至少可以说。> > > > > > >好的观点。我将事情安装通过欺骗> >更多> > > >社会工程的领域软件工程。如果自动> >依存关系可以> > > >解析器安装这样的事情,那么我想说的漏洞所在> > > >解析器,和> >我不在乎每一个大量的东西可能> >被安装。> > > >嗯例如:> >https://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm> >我显然可以注册一家名为JSON,劫持JSON > NPM >…接管世界。脆弱的代码,脆弱的业务>流程>等,但我认为总体上我们会更好覆盖> >重要的事情而不是无视外面的世界船舶的盒装软件> >客户。我担心一切看起来像钉子,因为我们有一把锤子。其他工具可能更合适。> > > > > >我们当然希望人们了解相关的安全问题> > > >。然而,我> >说恶意软件实例CVE的范围,而缺陷> > > >让恶意软件> >安装范围。恶意软件并不是缺陷。> > > >这意味着任何开发人员可以争议,导致CVE >“拒绝”,只需说“缓冲区溢出是故意,> >一个隐藏后门”听起来很荒谬,但就是这样的逻辑结果> >的决定。我敢肯定这不是我们想要的。 I meant to address distinct malware from a 3rd party (the "second type" in Brian's post), which seemed your concern when talking about dependency resolvers. When a vendor integrates malware into a product, the intention of the vendor is irrelevant, and the vendor doesn't get to redefine words. I believe that whether a violation happens in the scope of the code or not, compared to the legitimate purpose of the code, is what makes it relevant, in scope for a CVE or not. Phishing web sites and emails shouldn't get CVEs. Pure malware shouldn't get CVEs. However, if you buy a well-known, reputed AV product that contains vulnerabilities that may or may not have been put in intentionally and may or may not have been put in by a third party, that is in scope for a CVE. If you go to a curated app store that is supposed to contain only trustworthy apps, and install one later discovered to be malicious, a CVE could help and is in scope, in addition to an advisory and action by the vendor and curator. Regardless of the wisdom of using code from uncurated repositories (npm or such), a CVE appears appropriate on the presumption and representation that the vulnerable code serves a legitimate purpose, if the vulnerability is the result of a code flaw. That's in scope. The fact that code could be pulled isn't a vulnerability in the code that's in the repository. A product depending on the repository service being available and unchanged is a risky product; however it's not always obvious if it's in scope or out of scope of the CVE. I'm inclined to think that remote code availability and integrity issues are in scope for the CVE only if the software that includes it, makes representations that it is handling those issues securely. Vulnerabilities from business processes or misplaced trust are real, but violations that occur out of scope of the code should likely be out of scope of the CVE, unless the code is expected to handle them somehow. As to our previous discussion topic, smart contracts, CVEs appear in scope because the code should handle the vulnerable scenarios, regardless of whether vulnerable versions were seeded in the hope of getting someone rich to use them, or simply the result of mistakes. Pascal > > > > > > Pascal > > > > >