标签: GitHub

从 Stack Overflow 复制代码导致 GitHub 项目漏洞多

现在从网上找代码直接复制到项目中的做法成为程序员的一种常规操作,Stack Overflow 更是其中主要的代码来源。但是最近有研究显示,从 Stack Overflow 上复制代码凑到项目中会使出现漏洞的概率大大增加。 研究人员分析了 1325 个 Stack Overflow 帖子,并获取了其中 72 000 多段 C++ 代码,发现了其中包含有 29 种类型的 69 个漏洞。 这些漏洞出现在 2589 个 GitHub 仓库中,研究人员通知了受影响的 GitHub 项目作者,但只有少数人选择修复已知这些危险情况。 研究人员展示了含有漏洞的代码主要是以什么方式从 Stack Overflow 进入到 GitHub 中的,包括最经常发现的输入验证不正确、异常或异常情况的不正确检查与错误编码,比如复制代码不完整。     (稿源:开源中国,封面源自网络。)

Github 收购代码分析平台公司 Semmle 致力于查找零日漏洞及其变种

已被微软纳入麾下了开源代码托管平台 Github,刚刚宣布收购了一家名叫 Semmle 的代码分析平台公司。后者致力于查找零日漏洞,并对其变体展开自动化分析。Semmle 的语义代码分析引擎,允许开发者编写查询、识别大型代码库中的编程模式、搜索漏洞及其变种。此前,Semmle 已被谷歌、Uber、微软和诸多开源项目开发者用于提升其产品和服务的安全性。 微软表示,本次收购有助于让 Semmle 吸引到更多开发者,但现有的产品和客户并不会受到任何影响。 在接下来几个月里,您可期待 Semmle 与 Github 产品线实现更深层次的整合。此外 Semmle 透露,LGTM.com 将继续免费提供公共存储库和开源软件。 据悉,安全研究人员可借助 Semmle 简单的声明性查询,快速查找到代码中的相关漏洞。然后,这些团队会与 Semmle 社区分享他们的查询,以提升代码库中其它项目的安全性。 Nat Friedman 表示:作为软件安全社区的最新努力,没有一家公司可以独自完成每一个漏洞的查找、并为背后的开源供应链提供完整的保护。 好消息是,Semmle 正好可以填补这方面的空缺,因其采用了基于社区驱动的安全漏洞识别与预防措施。   (稿源:cnBeta,封面源自网络。)

GitHub 源码被黑客洗劫和勒索事件 微软也未能幸免

Git仓库被黑客洗劫和勒索的事件,似乎微软也未能幸免。微软确认其开源开发平台昨天也被黑客攻击,他们被要求支付款项才能归还他们窃取的数百个源码。黑客擦除了微软多达392个代码存储库,并提出勒索要求。此前,黑客攻击了包含微软在内的大批受害者的Git存储库,删除了所有源代码和最近提交的内容,并留下了支持比特币支付的赎金票据。 勒索信息如下: “要恢复丢失的代码并避免泄漏:将比特币(BTC)发送到我们的比特币地址,并通过电子邮件admin@gitsbackup.com与您联系,并附上您的Git登录信息和付款证明,” “如果您不确定我们是否有您的数据,请联系我们,我们会向您发送证明。您的代码已下载并备份到我们的服务器上,“ “如果我们在未来10天内未收到您的付款,我们会将您的代码公开或以其他方式使用。” GitLab安全总监Kathy Wang发表声明回应网络攻击: “我们已确定受影响的用户帐户,并已通知所有这些用户。根据我们的调查结果,我们有充分证据表明受损帐户的帐户密码以明文形式存储在相关存储库的部署中。“ Atlassian的安全研究员杰里米·加洛韦(Jeremy Galloway)已经独立证实,大量用户受到了这种黑客行为的影响。 GitHub建议启用双因素身份验证,为帐户添加额外的安全层。   (稿源:cnBeta,封面源自网络。)  

几大 Git 平台仓库被劫,黑客欲勒索比特币

数百名开发人员的 Git 仓库被黑客删除,取而代之的是赎金要求。 攻击于5月3日开始,包括 GitHub、Bitbucket 和 GitLab在内的代码托管平台都受到了影响。 目前已知的情况是,黑客从受害者的 Git 仓库中删除了所有源代码和最近提交的 Repo,只留下了 0.1 比特币(约 ¥3850)的赎金票据。 黑客声称所有源码都已经下载并存储在他们的一台服务器上,并且给受害者十天时间支付赎金,否则,他们会公开代码。 想要恢复丢失的代码并避免泄露:请将 0.1 比特币(BTC)发送至我们的比特币地址 1ES14c7qLb5CYhLMUekctxLgc1FV2Ti9DA,并将您的 Git 登录信息和付款证明发送至 admin@gitsbackup.com。如果您不确定我们是否有您的数据,请与我们联系,我们将向您发送证明,您的代码已下载并备份在我们的服务器上。如果我们在接下来的 10 天内没有收到付款,我们将公开代码或以其他方式使用。 在 GitHub 上搜索可发现已有 391 个仓库受影响,这些仓库的代码和提交信息均被一个名为 “gitbackup” 的账号删除。 尽管如此,BitcoinAbuse 平台显示,该比特币地址目前还未收到赎金。 一名用户指出 GitHub 在发现攻击后暂停帐户并进行调查:“GitHub 昨晚在他们调查时暂停了我的帐户,希望今天能听到他们的消息,我可能很幸运。” 据 ZDNet 的报道,好消息是,在深入挖掘受害者的案例后,StackExchange 安全论坛的成员发现黑客实际上没有删除,仅仅是改变了 Git 提交标头,这意味着在某些情况下可以恢复代码提交。 此页面提供了有关如何恢复损坏的 Git 仓库的说明。 最新消息,GitLab 的安全总监 Kathy Wang 告诉 BleepingComputer: 我们根据 Stefan Gabos 昨天提交的赎金票据确定了消息来源,并立即开始调查此问题。我们已确定受影响的用户帐户,并且已通知所有这些用户。根据调查结果,我们有充分证据表明,受损帐户的帐户密码以明文形式存储在相关存储库的部署中。我们强烈建议使用密码管理工具以更安全的方式存储密码,并尽可能启用双因素身份验证,这两种方法都可以防止出现此问题。 目前,平台和用户都在努力解决问题,此处正在持续讨论可能的解决方案。   (稿源:开源中国,封面源自网络。)

GitHub 撤下被泄露的 Snapchat 源码 黑客扬言重新上传

Snapchat 是一款主打“阅后即焚”功能的消息应用,不过近日,这款 app 的源码也在代码托管网上上玩了一回“阅后即焚”。事情的起因是,一位据说来自巴基斯坦东南部 Sindh 省 Tando Bago 村的“the handle i5xx”,在 GitHub 上创建了一个名叫“Source-Snapchat”的资源库。 尽管发稿时,该资源已经被 Snap 公司依据《数字千年版权法案》(DMCA)提出的版权撤除请求而被 GitHub 移除,但事件还是引起了很大的反响。 据悉,该资源库自称为‘SnapChat 源代码’,并通过苹果的 Objective-C 语言编写,所以曝光的应该是 iOS 版 Snapchat 应用的全部或部分内容。 不过当前,我们还无法确定它属于其中服务的一个小组件,还是该公司的一个单独项目。 至于发布者‘i5xx’的身份,其账号信息关联的是‘Khaled Alshehri’,但很可能是个假名。外媒 TNW 指出,其姓氏在巴基斯坦并不常见。 此外,账号简介链接到了一个位于沙特的在线服务,其提供从安全扫描、iCloud 删除,到软件开发和 iTunes 礼品卡销售在内的各种技术服务。 四天前,GitHub 发布了一份来自 Snap Inc. 的 DMCA 版权撤除请求,不过它可能是在更早之前提交的(在线时间或超过 2 个月)。 需要指出的是,Snap Inc. 在 DMCA 请求中使用的语气(多段纯大写字母组成的句子),传达出了一种切实的恐慌感(甚至措辞来不及做得更加严谨)。 Snapchat 源代码被泄露,有人将它放到了这个 GitHub 资源库中。我司无法给出确切的 URL 指向,也不会公开发布它。 显然,这从侧面反映了此前上传的资源库内容的重要性。 然而有知情者指出,本次泄露并非出于恶意,只是某位研究人员无法将他的某些发现传达给该公司。在 GitHub 根据 DMCA 请求撤除之后,他还威胁再次上传源代码,直到该公司正式作出回应。 不过事实是,Snap Inc. 在 HackerOne 上有一个活跃的账户和 bug 赏金计划,且响应速度极快 —— 安全研究人员是很容易与该公司取得联系的。 根据 HackerOne 的官方统计数据,其在 12 小时内回复了初步报告,并已支付超过 22 万美元的奖金。外媒 TNW 已经联系 Snap 发表评论,感兴趣的朋友可以留意我们的后续报道。         稿源:cnBeta.COM,编译自:TNW,封面源自网络;

GitHub 推出 Python 安全警告,识别依赖包的安全漏洞

GitHub 宣布了 Python 安全警告,使 Python 用户可以访问依赖图,并在他们的库所依赖的包存在安全漏洞时收到警告。 安全警告首次发布是在 2017 年 10 月,为了跟踪 Ruby 和 JavaScript 程序包中的安全漏洞。据 GitHub 介绍,从那时起,数以百万计的漏洞被发现,推动了许多补丁的发布。 GitHub 会根据 MITRE 的公共漏洞列表(CVE)来跟踪 Ruby gems、NPM 和Python 程序包中的公共安全漏洞。CVE 是一个条目列表;每个条目都包含一个标识号、一段描述以及至少一项公共参考。这非常有助于促使管理员快速响应、通过移除易受攻击的依赖或迁移到安全版本来修复漏洞。 当 GitHub 收到新发布的漏洞通知,它就会扫描公共库(已经选择加入的私有库也会被扫描)。当发现漏洞时,就会向受影响的库的所有者和有管理员权限的用户发送安全警告。在默认情况下,用户每周都会收到一封邮件,其中包含多达 10 个库的安全警告。用户也可以自己选择通过电子邮件、每日摘要电子邮件、Web 通知或 GitHub 用户界面来接收安全警告。用户可以在通知设置页面调整通知频率。 在某些情况下,对于发现的每个漏洞,GitHub 会尝试使用机器学习提供修复建议。针对易受攻击的依赖的安全警告包含一个安全级别和一个指向项目受影响文件的链接,如果有的话,它还会提供 CVE 记录的链接和修复建议。通用漏洞评分系统(CVSS)定义了四种可能的等级,分别是低、中、高和严重。 据 GitHub 介绍,开始的时候,安全警告只会涵盖最新的漏洞,并在接下来的数周内添加更多 Python 历史漏洞。此外,GitHub 永远不会公开披露任何库中发现的漏洞。 依赖图列出了项目的所有依赖,用户可以从中看出安全警告影响的项目。要查看依赖图,在项目中点击 Insights,然后点击 Dependency graph。 要在 Python 项目中使用依赖图,需要在 requirements.txt 或 pipfile.lock 文件中定义项目依赖。GitHub 强烈建议用户在 requirements.txt 文件中定义依赖。 要了解更多信息,请查看 GitHub文档。   稿源:开源中国社区,封面源自网络;

密码的锅,Gentoo 发布 GitHub 仓库被入侵事件报告

之前我们曾报道过“Gentoo Linux 的 GitHub 仓库被入侵,意图删除所有文件”的消息,Gentoo Linux 的 Github 仓库在6月28日晚上受到黑客攻击,并成功取得了组织的控制权。攻击者篡改了存储库的内容以及页面,并用恶意 ebuild 文件替换了 portage 和 musl-dev trees 中的文件,意图删除储存库上的所有文件。Gentoo 的开发者在发现问题后,发出预警邮件,Gentoo GitHub 组织权限被冻结。 之后,Gentoo 在官网发布多条公告说明事件的处理进度,直到 5 天后的7月3日,Gentoo 才正式将事件标记为已解决,恶意提交和被污染的文件已处理,Gentoo GitHub 组织被重新解锁。Gentoo 还在其官网上发布了一篇关于整个事件的详细报告,并表示收集的相关证据表明事件的根本原因是他们使用的密码方案过于简单,在某个站点上的披露使得攻击者很容易猜出在其他不相关网页的密码,致使攻击者获得了组织管理员的密码和访问权限。 稿源:开源中国,封面源自网络;

GitHub 在其内部日志中记录了明文密码

近期,有一定数量的用户认为,GitHub 密码重置功能中存在 Bug,公司内部日志内的明文格式记录了用户的密码。该公司表示,明文密码只向少数可以访问这些日志的 GitHub 员工公开,没有其他 GitHub 用户看到用户的明文密码。 GitHub 说,通常情况下,密码是安全的,因为它们是用 bcrypt 算法散列的。该公司指责其内部日志中存在明文密码的错误。只有最近重置密码的用户才受到影响,受影响的用户数量预计很低。数十名用户分享了他们今天早些时候在 Twitter 上收到的 GitHub 电子邮件的图片。最初,用户认为这是一个大规模的网络钓鱼攻击。GitHub 表示,它在例行审计中发现了它的错误,并明确表示它的服务器没有被黑客入侵。 稿源:freebuf,封面源自网络;

GitHub 安全警告计划已检测出 400 多万个漏洞

Github 去年推出的安全警告,极大减少了开发人员消除 Ruby 和 JavaScript 项目漏洞的时间。GitHub 安全警告服务,可以搜索依赖寻找已知漏洞然后通过开发者,以便帮助开发者尽可能快的打上补丁修复漏洞,消除有漏洞的依赖或者转到安全版本。 根据 Github 的说法,目前安全警告已经报告了 50 多万个库中的 400 多万个漏洞。在所有显示的警告中,有将近一半的在一周之内得到了响应,前7天的漏洞解决率大约为 30%。实际上,情况可能更好,因为当把统计限制在最近有贡献的库时,也就是说过去 90 天中有贡献的库,98% 的库在 7 天之内打上了补丁。 这个安全警报服务会扫描所有公共库,对于私有库,只扫描依赖图。每当发现有漏洞,库管理员都可以收到消息提示,其中还有漏洞级别及解决步骤提供。 安全警告服务现在只支持 Ruby 和 JavaScript,不过 Github 表示 2018 年计划支持 Python。 稿源:cnBeta、开源中国,封面源自网络;

开发者噩梦:欧盟希望过滤上传到互联网的所有代码

欧盟的一项提案要求托管内容的所有平台检查所有上传的内容有无侵犯版权,这可能会使软件的成本更高昂。欧盟考虑的一项版权提案旨在让盗版者更难共享内容和媒体,但是这张网撒得太广了,可能无意中阻碍程序员。 欧盟考虑的一项版权提案要求托管由用户上传的大量内容的任何平台扫描所有内容,以确保没有侵犯版权。 该提案旨在防止媒体盗版,但可能会给使用代码仓库 GitHub 等服务的广大开发者带来严重影响,按照新法律 GitHub 将被迫过滤代码。 正如 GitHub 指出的那样,自动过滤代码对于独立程序员和大企业程序员来说都是毁灭性的。面临的问题可能包括:误报/漏报、丢失依赖项、许可证混淆以及不必要的负担阻碍创新。 版权提案仍在讨论中,已经有人开始竭力阻止实施。 提案有什么样的内容?为何让码农们深为担忧? 该提案的第 13 条专门涉及自动内容过滤器的实施,这也是让 GitHub 及其他欧洲程序员们深为担忧的部分。 第 13 条规定:“ 如果提供商存储用户上传的大量作品或其他主题,并允许公众访问这些内容 ”,须与版权所有者合作,实施措施以防止内容被非法共享。 “那些措施(比如使用有效的内容识别技术)应该是适当的、相称的,”该提案表示。第 13 条进一步提到了内容识别技术是发现版权侵犯行为的最佳实践的一部分,因此过滤器很可能是通过的任何新版权法的最终条文的一部分。 然而,哪些类型的内容要过滤却没有明确规定。撒一张这么大的网让 GitHub 和 Save Code Share 的成员们深为担忧,自由软件基金会欧洲分会和开放论坛欧洲共同发起了 Save Code Share,这场请愿活动旨在阻止第 13 条实施,呼吁欧盟的政策制定者重新考虑或摈弃第 13 条。他们认为,对于处理代码、文档、音频和视频的开发者来说,版权合规检查完全实现自动化是不可行的。 如果真是那样子,代码共享平台就需要招聘众多的人员帮助做好版权合规工作,Facebook 和 YouTube 等社交媒体平台之前就是这么做的。 不管怎样,通过使用 Git 及其他软件工具而共享的大量内容需要 GitHub 等面向开发的平台公司实施自动化过滤机制,确定什么内容可以共享、什么不可以共享。 GitHub 的政策经理艾阿•沃尔默(Abby Vollmer)在发给 IT 外媒 The Register 的电子邮件中表示,如果美国开发者/开发商在欧洲开展工作/业务,需要遵守同样的这些规定。 GitHub 认为,对于软件开发者而言,由于应用程序常常牵涉许多不同的贡献者和不同层的代码(这些代码也许采用不同的许可证),可能出现误报或漏报这个问题显得尤为突出。 此外,要求代码共享平台删除没有许可证的代码 “ 审查机器 ”是否来自欧盟? 欧洲议会议员朱莉娅•里达(Julia Reda)细述了版权提案中另外一些令人担忧的条文,它们适用于编程平台及其他内容共享网站,这些平台和网站都将受到该提案的影响: 平台需要为它们托管的所有版权保护的内容获得许可证,她认为这几乎是不可能的,对于代码共享平台而言尤为如此。 平台需要阻止版权保护的内容被上传,她认为这就要求使用内容过滤器。 因为上传/阻止的内容将被去除标识符,内容过滤器无法处理任何个人数据,她表示因而不可能对针对过度过滤的纠错进行归档。 扫描的文件将针对所有上传的内容予以检查,里达认为此举违反了欧盟在一般监视方面的禁令。 过滤不适用于在线市场(如 eBay)、互联网服务提供商(ISP)、研究资料库或云存储服务。里达指出,这些服务并非被免除许可证要求,因令人混淆的语言而容易面临诉讼。 围绕版权提案的争论从未停过,所以现在判断它的一些更广义、更苛刻或不一致的部分条文是否会成为法律还为时尚早。 这项合理的提案其初衷是确保表演者、创作者和出版者获得作品的报酬,但未必很适合其他社区;谁想发表意见,欢迎联络欧洲议会议员、理事会成员和欧盟委员,确保其心声被听到。 稿源:cnBeta、云头条,封面源自网络;