1.Windows 10源代码泄漏实为1.2GB？微软暂未回应
2.常见的源码Web源码泄漏及其利用
3.微软如何回应43 GB Windows源代码泄漏事件？
4.主流静态代码检测工具(SAST)
5.Spring Boot引起的“堆外内存泄漏”排查及经验总结
Windows 10源代码泄漏实为1.2GB？微软暂未回应
Windows 源代码泄漏事件震惊微软，但真相仍未明朗
近日，泄漏The排查 Register的一篇报道指出，Windows 的源码源代码疑似在网上被大规模泄露，总量达到了惊人的泄漏TB，这一消息让众多用户担忧。排查新版云划算源码然而，源码微软对此暂无官方回应。泄漏 据Beta Archive FTP服务器的排查回应，他们已经紧急从服务器和相关列表中移除了这些疑似泄露的源码数据，并正在进行深入审核，泄漏以确保无遗漏。排查FTP服务器管理员Andy澄清，源码最初传闻的泄漏TB其实只有1.2GB，其中包含了个系统版本。排查他强调，由于体积较小，这些代码很可能并非核心源代码。 外界猜测，如果泄露影响不大，微软通常会迅速辟谣。但目前微软似乎正忙于内部调查，无暇对外公开详细信息。对于此次事件的真相，公众可能只能等待微软的官方声明，毕竟他们可能不会轻易透露所有细节。 这场泄露事件的详情仍扑朔迷离，我们只能等待微软的官方解释。您认为这起事件会对微软产生怎样的影响呢？微软的应对策略和后续行动将为我们揭示更多真相。常见的Web源码泄漏及其利用
Web源码泄漏漏洞及利用方法
Git源码泄露是由于在执行git init初始化目录时，会在当前目录下自动创建一个.git目录，用于记录代码变更等信息。若未将.git目录删除即发布到服务器，攻击者可通过此目录恢复源代码。修复建议：删除.git目录或修改中间件配置以隐藏.git隐藏文件夹。
SVN源码泄露源于其使用过程中自动生成的.svn隐藏文件夹，包含重要源代码信息。若网站管理员直接复制代码文件夹至WEB服务器，面膜网站源码暴露.svn隐藏文件夹，攻击者可利用.svn/entries文件获取服务器源码。修复方法：删除web目录中的所有.svn隐藏文件夹，严格使用SVN导出功能，避免直接复制代码。
Mercurial（hg）源码泄露通过生成的.hg文件暴露，漏洞利用工具为dvcs-ripper。运行示例需具体说明。
CVS泄露主要针对CVS/Root和CVS/Entries目录，直接暴露泄露信息。修复工具为dvcs-ripper，运行示例同样需具体说明。
Bazaar/bzr泄露为版本控制工具泄露问题，因其不常见但多平台支持，同样存在通过特定目录暴露源码的风险。具体修复方法与运行示例需进一步说明。
网站备份压缩文件泄露是管理员将备份文件直接存放于Web目录，攻击者通过猜测文件路径下载，导致源代码泄露。常见备份文件后缀需具体列出，利用工具御剑用于这类漏洞的利用。
WEB-INF/web.xml泄露暴露了Java WEB应用的安全目录，若直接访问其中文件需通过web.xml文件映射。WEB-INF目录主要包括文件或目录，通过web.xml文件推断类文件路径，最后直接访问类文件，通过反编译得到网站源码。
.DS_Store文件泄露源于Mac系统中Finder保存文件展示数据的文件，每个文件夹下对应一个。若上传部署到服务器，可能造成文件目录结构泄漏，特别是备份文件、源代码文件的泄露。利用工具为github.com/lijiejie/ds_...
SWP文件泄露为编辑文件时产生的临时文件，是隐藏文件，若程序意外退出则保留。直接访问并下载.swp文件，取名网站源码删除末尾的.swp后，可获得源码文件。
GitHub源码泄露通过关键词搜索功能，容易找到目标站点的敏感信息，甚至下载网站源码。此类泄露源自代码托管平台，需注意个人代码管理安全。
总结，Web源码泄漏涉及多个环节，从代码版本控制到备份存储，再到代码托管平台，每个环节都可能成为攻击点。修复策略包括删除隐藏文件、严格使用版本控制功能、加强代码备份安全措施以及提高代码托管平台安全意识。
微软如何回应 GB Windows源代码泄漏事件？
微软对Windows源代码泄露事件采取行动
近期，一场涉及Windows XP、Windows Server 等众多旧版系统及其相关MS DOS版本的 GB源代码泄露事件引起了广泛关注。这场意外的披露，不仅揭示了历史遗留的细节，也对当今网络安全构成了潜在威胁。 据透露，泄漏的代码涵盖了Windows XP的创意，甚至有一个主题让操作系统呈现出Mac般的外观，这无疑是技术爱好者们的乐园，他们借此挖掘出无数隐藏的秘密。然而，微软在初始阶段对这一事件保持沉默，直到知名科技博主保罗·特罗特成功从公司内部获取了回应：“我们正在对这一情况展开深入调查。” 尽管Windows XP和Server 早已是过时的操作系统，但其完整源代码的泄露意味着任何未修复的漏洞都可能被利用，对现代Windows系统，包括Windows ，构成潜在风险。因为许多自Windows XP时代沿用至今的代码并未进行更新，这为黑客提供了可能的攻击入口。 微软此次的口袋助理源码反应速度和后续的调查行动，无疑显示出他们对保障用户数据安全的重视。随着技术发展，对旧版系统漏洞的挖掘和修复工作将愈发重要，以防止历史遗留问题影响到今日的数字世界。主流静态代码检测工具(SAST)
静态代码检测工具，简称SAST，是软件开发过程中不可或缺的分析与检查源代码的工具，旨在发现并解决潜在的缺陷、漏洞和安全风险。
自动化检测是静态代码检测工具的显著特点之一，它可以自动分析和检查源代码，无需人工逐行检查，从而提高了检测效率和准确性。
静态代码检测工具支持多种编程语言，包括但不限于Java、C/C++、Python、JavaScript等，能够满足不同项目的需求。
工具能够识别代码中的潜在问题，如内存泄漏、空指针引用、未使用的变量、代码重复等，帮助开发者发现潜在的bug和优化机会。
此外，静态代码检测工具还可以检查代码的风格和规范是否符合规范，如缩进、命名规范、注释规范等，有助于开发团队保持一致的代码风格。
许多静态代码检测工具提供了可定制的配置选项，可以根据项目的特定需求进行调整，灵活地控制检测规则和行为。
部分静态代码检测工具可以与常用的集成开发环境（IDE）集成，提供实时检测和即时反馈，方便开发者在开发过程中及时发现和修复问题。网站源码编译
检测结果报告是静态代码检测工具的另一个重要功能，通常会包括问题的详细描述、位置和建议修复措施，并提供可视化展示，帮助开发者更直观地理解和解决问题。
以下是一些主流的静态代码检测工具：
SonarQube：这是一个开源的静态代码检测平台，支持多种编程语言，如Java、C++、C#、Python等。它能够检测代码中的潜在问题、漏洞、代码重复和代码覆盖率，并提供详细的报告和建议。
FindBugs：这是一个基于静态分析的Java代码缺陷检测工具，能够检测出代码中的潜在问题、错误和不良实践，并给出相应的修复建议。FindBugs的规则库非常丰富，并且支持自定义规则。
WuKong：这是一款国产静态代码检测工具，支持多种语言，如Java、C++、C#、Python、PHP等。它可以检测编码规则、缺陷及安全漏洞并给出修复建议。WuKong兼容麒麟、龙芯等国产软硬件，拥有自主知识产权，可灵活进行定制。
Coverity：Coverity支持超过种编译器（主要C/C++），可在编译不通过情况下检测，是一款针对C、C++、C#和Java等编程语言的静态代码检测工具，能够检测代码中的潜在问题、漏洞和性能问题，并给出相应的修复建议。Coverity具有高度可定制性和可扩展性。
Fortify：支持规则自定义，包括合规信息的识别。支持Java、C#、C/C++、Python、Ruby等超种语言。它更侧重于安全漏洞检测，支持规则自定义，包括合规信息的识别。Fortify通过基于规则和漏洞模式的检测引擎来分析代码，识别安全漏洞并提供相应的修复建议。
Checkmarx：Checkmarx支持多种语言，如Java、JSP、JavaScript、VBSript、C#等超种语言。它能够查找安全漏洞、质量缺陷、逻辑问题等。CxSAST无需搭建软件项目源代码的构建环境即可对代码进行数据流分析。
Spring Boot引起的“堆外内存泄漏”排查及经验总结
为了更好地实现对项目的管理，我们将组内一个项目迁移到MDP框架（基于Spring Boot），随后我们就发现系统会频繁报出Swap区域使用量过高的异常。笔者被叫去帮忙查看原因，发现配置了4G堆内内存，但是实际使用的物理内存竟然高达7G，确实不正常。JVM参数配置是“-XX:MetaspaceSize=M -XX:MaxMetaspaceSize=M -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=m -XX:InitialCodeCacheSize=m, -Xssk -Xmx4g -Xms4g,-XX:+UseG1GC -XX:G1HeapRegionSize=4M”，实际使用的物理内存如下图所示：
使用Java层面的工具定位内存区域（堆内内存、Code区域或者使用unsafe.allocateMemory和DirectByteBuffer申请的堆外内存）。
笔者在项目中添加-XX:NativeMemoryTracking=detailJVM参数重启项目，使用命令jcmd pid VM.native_memory detail查看到的内存分布如下：
发现命令显示的committed的内存小于物理内存，因为jcmd命令显示的内存包含堆内内存、Code区域、通过unsafe.allocateMemory和DirectByteBuffer申请的内存，但是不包含其他Native Code（C代码）申请的堆外内存。所以猜测是使用Native Code申请内存所导致的问题。
为了防止误判，笔者使用了pmap查看内存分布，发现大量的M的地址；而这些地址空间不在jcmd命令所给出的地址空间里面，基本上就断定就是这些M的内存所导致。
使用系统层面的工具定位堆外内存。
因为已经基本上确定是Native Code所引起，而Java层面的工具不便于排查此类问题，只能使用系统层面的工具去定位问题。
首先，使用了gperftools去定位问题。
从上图可以看出：使用malloc申请的的内存最高到3G之后就释放了，之后始终维持在M-M。笔者第一反应是：难道Native Code中没有使用malloc申请，直接使用mmap/brk申请的？（gperftools原理就使用动态链接的方式替换了操作系统默认的内存分配器（glibc）。）
然后，使用strace去追踪系统调用。
因为使用gperftools没有追踪到这些内存，于是直接使用命令“strace -f -e"brk,mmap,munmap" -p pid”追踪向OS申请内存请求，但是并没有发现有可疑内存申请。
接着，使用GDB去dump可疑内存。
因为使用strace没有追踪到可疑内存申请；于是想着看看内存中的情况。就是直接使用命令gdp -pid pid进入GDB之后，然后使用命令dump memory mem.bin startAddress endAddressdump内存，其中startAddress和endAddress可以从/proc/pid/smaps中查找。然后使用strings mem.bin查看dump的内容，如下：
从内容上来看，像是解压后的JAR包信息。读取JAR包信息应该是在项目启动的时候，那么在项目启动之后使用strace作用就不是很大了。所以应该在项目启动的时候使用strace，而不是启动完成之后。
再次，项目启动时使用strace去追踪系统调用。
项目启动使用strace追踪系统调用，发现确实申请了很多M的内存空间，截图如下：
使用该mmap申请的地址空间在pmap对应如下：
最后，使用jstack去查看对应的线程。
因为strace命令中已经显示申请内存的线程ID。直接使用命令jstack pid去查看线程栈，找到对应的线程栈（注意进制和进制转换）如下：
这里基本上就可以看出问题来了：MCC（美团统一配置中心）使用了Reflections进行扫包，底层使用了Spring Boot去加载JAR。因为解压JAR使用Inflater类，需要用到堆外内存，然后使用Btrace去追踪这个类，栈如下：
然后查看使用MCC的地方，发现没有配置扫包路径，默认是扫描所有的包。于是修改代码，配置扫包路径，发布上线后内存问题解决。
为什么堆外内存没有释放掉呢？
虽然问题已经解决了，但是有几个疑问。带着疑问，直接看了一下 Spring Boot Loader那一块的源码。发现Spring Boot对Java JDK的InflaterInputStream进行了包装并且使用了Inflater，而Inflater本身用于解压JAR包的需要用到堆外内存。而包装之后的类ZipInflaterInputStream没有释放Inflater持有的堆外内存。于是以为找到了原因，立马向Spring Boot社区反馈了这个bug。但是反馈之后，就发现Inflater这个对象本身实现了finalize方法，在这个方法中有调用释放堆外内存的逻辑。也就是说Spring Boot依赖于GC释放堆外内存。
使用jmap查看堆内对象时，发现已经基本上没有Inflater这个对象了。于是就怀疑GC的时候，没有调用finalize。带着这样的怀疑，把Inflater进行包装在Spring Boot Loader里面替换成自己包装的Inflater，在finalize进行打点监控，结果finalize方法确实被调用了。于是又去看了Inflater对应的C代码，发现初始化的使用了malloc申请内存，end的时候也调用了free去释放内存。
此时，怀疑free的时候没有真正释放内存，便把Spring Boot包装的InflaterInputStream替换成Java JDK自带的，发现替换之后，内存问题也得以解决了。
再次看gperftools的内存分布情况，发现使用Spring Boot时，内存使用一直在增加，突然某个点内存使用下降了好多（使用量直接由3G降为M左右）。这个点应该就是GC引起的，内存应该释放了，但是在操作系统层面并没有看到内存变化，那是不是没有释放到操作系统，被内存分配器持有了呢？
继续探究，发现系统默认的内存分配器（glibc 2.版本）和使用gperftools内存地址分布差别很明显，2.5G地址使用smaps发现它是属于Native Stack。内存地址分布如下：
到此，基本上可以确定是内存分配器在捣鬼；搜索了一下glibc M，发现glibc从2.开始对每个线程引入内存池（位机器大小就是M内存），原文如下：
按照文中所说去修改MALLOC_ARENA_MAX环境变量，发现没什么效果。查看tcmalloc（gperftools使用的内存分配器）也使用了内存池方式。
为了验证是内存池搞的鬼，就简单写个不带内存池的内存分配器。使用命令gcc zjbmalloc.c -fPIC -shared -o zjbmalloc.so生成动态库，然后使用export LD_PRELOAD=zjbmalloc.so替换掉glibc的内存分配器。其中代码Demo如下：
通过在自定义分配器当中埋点可以发现实际申请的堆外内存始终在M-M之间，gperftools监控显示内存使用量也是在M-M左右。但是从操作系统角度来看进程占用的内存差别很大（这里只是监控堆外内存）。
使用不同分配器进行不同程度的扫包，占用的内存如下：
为什么自定义的malloc申请M，最终占用的物理内存在1.7G呢？因为自定义内存分配器采用的是mmap分配内存，mmap分配内存按需向上取整到整数个页，所以存在着巨大的空间浪费。通过监控发现最终申请的页面数目在k个左右，那实际上向系统申请的内存等于k * 4k（pagesize） = 2G。
为什么这个数据大于1.7G呢？因为操作系统采取的是延迟分配的方式，通过mmap向系统申请内存的时候，系统仅仅返回内存地址并没有分配真实的物理内存。只有在真正使用的时候，系统产生一个缺页中断，然后再分配实际的物理Page。
整个内存分配的流程如上图所示。MCC扫包的默认配置是扫描所有的JAR包。在扫描包的时候，Spring Boot不会主动去释放堆外内存，导致在扫描阶段，堆外内存占用量一直持续飙升。当发生GC的时候，Spring Boot依赖于finalize机制去释放了堆外内存；但是glibc为了性能考虑，并没有真正把内存归返到操作系统，而是留下来放入内存池了，导致应用层以为发生了“内存泄漏”。所以修改MCC的配置路径为特定的JAR包，问题解决。在发表这篇文章时，发现Spring Boot的最新版本（2.0.5.RELEASE）已经做了修改，在ZipInflaterInputStream主动释放了堆外内存不再依赖GC；所以Spring Boot升级到最新版本，这个问题也可以得到解决。