再保险:定义什么是CVE值得下载/安装和容器

我有困难有一些语句:“如果CVE ID请求的起源似乎无关,写代码,然后(有时但不是100%的时间)CVE ID请求被拒绝建议和供应商商量。”It can be very difficult to "consult with the vendor". It's much, much easier to just disclose the vulnerability without a CVE. I'm afraid that the above policy is a strong incentive against using CVE identifiers. Also, I'm confused by the paragraph with the ASUS example as it seems to contradict the preceding one. Pascal On 06/07/2016 11:14 PM, Common Vulnerabilities & Exposures wrote: > Kurt – > > As you are well aware, CVE assignment is never an exact science. The > following is a description of our current practice: > > > · The question of whether it is "software acting exactly as > it is designed" depends on who sends the CVE ID request. For example, > it is plausible for a vendor's server to offer the same executable > code (or update service) through both HTTP and HTTPS, and the URL > hardcoded into a client-side product was -- by design -- supposed to > start with https, but it started with http by accident. Thus, if it > is a vendor-initiated request for a CVE ID to tag a required security > update for their customers, then the CVE ID request is always > accepted. > > · If the origin of the CVE ID request seems unrelated to the > party that wrote the code, then (sometimes but not 100% of the time) > the CVE ID request is rejected with a suggestion to consult with the > vendor. > > · It would be hard to achieve 100% rejections, even if a CNA > wanted to, because the person sending the CVE ID request may neglect > to mention, or may be unwilling to mention, the precise nature of the > problem. A large fraction of the population believes that it is > always a vulnerability for any product to continuously make requests > for executable code over unencrypted HTTP, with no other integrity > protection, and execute code whenever a response is received. Because > that much is obvious in their world view, their vulnerability > description may focus on other details, such as file-format > manipulation, etc. > > · Our prevailing opinion is that, for this > HTTP/executable-code scenario, the best a CNA can do is assign CVE > IDs in cases where they believe CVE consumers want those IDs to > exist. If the requester sends a credible description of high > exploitation likelihood, and there is no counterclaim from the vendor > itself that this is "software acting exactly as it is designed," then > it qualifies for a CVE ID. > > This matches what happened for ASUS (the vendor refused to respond at > all). If another requester does not describe exploitation likelihood > or asserts that there is essentially no exploitation likelihood, and > there is no clarification from the vendor, then the request can be > rejected on the "software acting exactly as it is designed" grounds. > > In other words, existence of a CVE ID should depend a little less on > a comprehensive theory of what a vulnerability is, and depend a > little more on judgment about whether the ID will help real-life > organizations with risk management. This requires a little more work > from the CNA, but makes CVE more useful than with either the 100% > accept or 100% reject options. > > Regards, > > The CVE Team > > > > > From: owner-cve-editorial-board-list@lists.mitre.org > [mailto: owner-cve-editorial-board-list@lists.mitre.org代表> Kurt Seifried >发送:周一,06年6月,2016年12:18点>:cve-editorial-board-list > < cve-editorial-board-list@lists.mitre.org > >主题:定义有什么CVE值得下载/安装>和容器> >所以我看过的经典“CVE安全漏洞,一个>安全漏洞是跨越信任边界”。> >这显然是开放的,各种各样的解释,例如>密码我们都同意一个秘密后门硬编码>密码CVE,但是应用程序有一个默认的密码>,然后被迫改变一旦你登录吗?什么应用程序>必须暴露在网络(引入一个种族,一个>攻击者可以先在)?一般来说我们有一个很好的>的密码的界限(记录?多变的吗?>有一个现实的安全的方法来部署这个产品?)。> >首先一个小故事:我的儿子玩"我很多,所以我要>设置一个服务器。当然是我发现了一些软件,设置>烦人(有些奇怪的依赖关系不打包我>平台的选择)。所以我想“嘿,让我们找到一个码头工人>容器!”,幸运的是有几个:> >https://github.com/5t111111/docker-pocketmine-mp/blob/master/Dockerfile> >你会注意它的线:> >运行cd PocketMine-MP & & wget - q - o - >http://cdn.pocketmine.net/installer.sh| bash - s -β- v > >这是一个幻想的方式说“去>http://cdn.pocketmine.net/installer.sh并运行它”幸运的是这是由早先> > >稍微减轻用户pocketmine > >声明这意味着命令运行作为一个用户,而不是根。>但github的快速搜索显示:> >https://github.com/search?utf8=%E2%9C%93&q=RUN + bash + wget + + http&type = Code&ref = searchresults> >,例如显示:> >https://github.com/wyvernnot/docker-minecraft-pe-server/blob/master/Dockerfile> >不降级到用户,而是运行脚本作为>根。所以点做我们在沙地上画一条线,“随机>下载东西,并运行它作为CVE值得吗?我的想法:> >,让它少CVE值得:> > 1)文档提及这是做什么,这是危险> 2)降低到更少的特权用户> 3)使用HTTPS服务内容> 4)使用一个众所周知的/值得信赖的网站服务内容> > >更CVE值得:> > 1)没有文档/提到它是做什么> 2)以特权用户身份运行命令(如根)> 3)使用HTTP下载内容(和没有端到端>签署/支票)> 4)使用基本随机服务器没有人听说过> 5)广泛应用(例如集装箱在码头工人>注册)> >例如Dockerfile Nginx: > >https://github.com/nginxinc/docker-nginx/blob/11fc019b2be3ad51ba5d097b1857a099c4056213/mainline/alpine/Dockerfile> > TL;博士:他们GPG密钥指纹作为env变量> Dockerfile: > > env GPG_KEYS B0F4253373F8F6F510D42178520A9993A1C052F8 > >他们后来下载键和用它来验证nginx他们下载tarball >: > > & & GPG——keyserver ha.pool.sks-keyservers.net > <http://ha.pool.sks-keyservers.net> >——recv-keys " $ GPG_KEYS " \ > & & gpg——批量验证nginx.tar.gz。asc nginx.tar。广州\ > >所以他们肯定是想做正确的事(我需要>确认这将实际误差在构建如果键>不是可用/错误的关键是为asc签名是坏的)和>假设它能够正常工作(一个错误触发的码头工人建立>中止)然后显然是安全的,不需要反暴力极端主义。> >但大多数容器没有做这样的事情,甚至没有关闭,>,我觉得我们需要开始分配CVE看起来很多>的受欢迎的容器Dockerfiles很没有安全感,他们如何>构建软件。> > > > > - - > Kurt Seifried——红帽产品安全——云> PGP A90B F995 7350 148 f 66高炉7554 160 d 4553 7993 > e26红帽产品安全联系:> secalert@redhat.com <mailto: secalert@redhat.com> >