标签归档:sandbox

Linux系统安全_sandbox_seccomp-bpf

        linux3.5以后linux支持了Will Drewry的Seccomp-BPF的特性。Seccomp-BPF是建立在能够发送小的BPF(BSD Packet Filter)程序,有内核来执行。这个特性起先源于tcpdump的设计,因为性能的原因,可以直接在内核中运行。BPF相对与内核是不可信的,因此, 限制了有限的数量。值得注意的是,他们不能循环,限定单一函数的执行时间,以及大小,并允许内核知道他们的永远终止。

BPF(BSD Packet Filter)是一种用于Unix内核网络数据包的过滤机制。Linux之前包过滤LPF。Linux随着版本的不同,所支持的捕获机制也有所不同。2.0之前的内核版本,对Socket使用类型SOCK_PACKET,调用形式是Socket(PF_INET,SOCK_PACKET,int proctol),但这种用法已经过时,2.2之后,提出的一种新的协议簇,PF_PACKET来实现捕获机制,调用形式为:socket(PF_PACKET, int socket_type, int protocol),其中socket类型可以是SOCK_RAW,和SOCK_DGRAM,SOCK_RAW 类型使得数据包从数据链路层取得后,不做任何修改,直接传递给用户数据,而SOCK_DGRAM,则要对数据包进行加工(cooked),把数据包的数据链路层头部去掉,而使得一个通用结构sockaddr_ll来保存链路信息。

使用2.0版本内核捕获数据包存在多个问题,首先,SOCK_PACKET方式使用结构sockaddr_pkt来保存数据链路层信息,该结构缺乏包类型信息;其次,如果参数MSG_TRUNC传递给读包函数recvmsg, recv, recvfrom 等,则函数返回的数据包长度是实际读到的包数据长度,而不是数据包的真正长度。

PF_PACKET方式规避上以上的问题,在实际应用中,用户程序显然希望直接得到“原始”数据包,因此使得SOCK_RAW类型最好。Libpcap使用的SOCK_DGRAM.从而也必须为数据包合成一个“伪”链路层头部(sockaddr_ll).1,某些类型的设备数据链路层头部不可用,例如linux 内核的ppp协议,实现代码对ppp数据包的支持的不可靠,2在捕获设备为any时,所有设备意味着libpcap对所有的接口进行捕获。需要要求对所有数据包有相同的数据链路头部。具体的详细描述:http://www.linuxjournal.com/article/4852

    BPF是一种过滤机制,有网络阀(Network tap)和过滤包组成,网络阀用于从网卡设备驱动处收集网络数据包拷贝,并负责向已注册监听的用户态应用程序递交数据,过滤器则是用于决定收集的网络数据是否满足过滤器要求,满足条件的则进行后继的拷贝工作,否则丢弃该数据。

    该图的过程为:当数据包到达网络接口时,链路层的设备驱动程序通常是将数据包直接传送给协议栈进行处理。而当BPF在该网络接口注册监听时,链路层驱动程序将数据包传送给协议栈之前,先会首先调用BPF。BPF负责将此数据包指针传递至每个监听进程指定的内核过滤器,这些用户自定义的过滤器决定数据包是否被接受,以及数据包中的那些内容将被接受,对于每一个决定接受数据包的过滤器,BPF此时才进行数据拷贝工作,将所需的数据拷贝至于过滤器相连的缓冲区中,以供用户监听进程读取。数据拷贝结束后,网络设备驱动程序重新获得系统控制权,系统进行正常的网络协议处理。我们注意到BPF是先对数据包过滤,在缓冲,避免了类似SUN的NIT过滤机制,先缓冲每个数据包直到用户读取数据时在过滤造成的效率问题。

    BPF 的设计思路和当时的计算机的硬件发展有大关系,相对较老的CSPF(CMU/Stanford Packet Filter)它有两大特点,1 :基于寄存器的过滤机制,而不是早期的内存堆栈过滤机制,2:直接使用独立的,非共享的内存缓冲区。同时,BPF在过滤算法上也有很大进步(有人也做了一些优化BPF+),它使用了无环控制流图(CFG,control flow graph).而不是老式的布尔表达式树(Boolean expression tree)。

下面说一下BPF的包过滤模式:

    包过滤可以看作是针对数据包的布尔函数运算。如果返回值为真,那么内核为监听程序拷贝数据,反之则丢弃。形式上包过滤由一个或者多个谓词判断的AND操作和OR操作组成。

    包过滤在具体的实现上是通过将数据包简单的看作一个字节数组,谓词判断根据具体的协议映射到数组的特定位置进行判断过滤工作。例如,判断数据包是否是ARP协议,只需要盘点数组的第13,14个字节是否为0×0806。因此,包过滤的算法的中心任务,是使用最少的判断操作。

    布尔表达式树理解上比较直观,它的每一个叶子结点即一个谓词判断,而非叶子结点则为AND或OR操作。而CFG算法是一种特殊的状态机,图中每一个非叶节点代表的是对数据包进行谓词判断操作,而边则是判断的结果。在CFG中,只存在2个叶子结点,分别代表过滤通过True和未通过Flase。
CSPF主要有3个缺点,1:过滤操作使用的栈在内存中被模拟,维护栈指针需要使用若干的加/减等操作,而内存操作时现代计算机架构的主要瓶颈。2:布尔表达树造成了不需要的重复计算。3不能分析数据包的变长头部。BPF使用的CFG算法,实际上是一种特殊的状态机,每一个节点代表了一个谓词判断,而左右分别对应了判断失败和成功后的跳转,跳转后又是谓词判断,这样反复操作,直到到达成功或失败的终点。CFG算法的优点在于把对数据包的分析信息直接建立在图中。从而不需要重复计算。CFG是一种“快速的,一直向前”的算法。

BPF包过滤模式的实现,BPF采用了一种过滤器伪机的方式(filter Pseudo-machine)。BPF伪机器方式是一个轻量级,高效的状态机。对BPF过滤代码进行解释,BPF过滤机过滤代码形式为”opcode jt jf k”,分别代表了操作码和寻址方式,判断正确的跳转和失败的跳转,以及操作所使用的通用数据域。

    BPF过滤代码从逻辑上看,很类似汇编语言,但它实际上是机器语言,注意到上述的3个域的数据都是int和char型。显然,有用户来写过滤代码太过于复杂,但这种设计更适合用于操作硬件。特别用来编写需要写少量固定序列的硬件驱动程序。BPF实际上是一组基于状态机匹配的过滤序列,用于简单的数据包模式匹配。用指令集简单的将上图描述如下:

    每个匹配包至少包含4个元素,定义为一个结构体如下:

    其很显然应该是一个状态驱动的循环:

看看linux实现的代码,基本上是这样实现的。

    BPF用于很多的抓包程序,在linux中,一般内核自动编译进了af_packet这个驱动,因此只需要在用户态配置一个PACKET的socket,然后将filter配置进内核即可,使用setsockopt的SO_ATTACH_FILTER 命令,这个filter是在用户空间配制的,比如tcpdump应用程序,tcpdump和内核BPF过滤器的关系类似iptables与netfilter的关系,只是Netfilter实现了match/target的复合配合,而BPF的target则只是选择是否要与不要。

    回到主题上来,seccomp-bpf在使用BPF的时候,借鉴了其思想。
大量的系统调用暴露在用户空间,在程序的整个生命周期内并没有使用。而随着系统调用的改变和成熟,bug的发现和根除,一套可用的系统调用是满足用户程序基本的调用。将可以产生出一组尽量少的系统调用暴露在用户空间。系统调用的过滤就是在应用程序的使用中。

Seccomp过滤器提给了一种手段,为一个进程调用系统调用时指定了过滤器,而这个过滤器则是BPF。BPF作为socket过滤器不同之处则是操作当前的user_regs_struct数据结构,这需要预先定义好系统调用的ABI和定义过滤规则。但系统调用的参数保存在用户空间,但要验证该参数是否安全是非常困难的。

    Seccomp用户无法避免TOCTOU (time-of-check-time-of-use)系统调用对框架的注入式攻击。如一个恶意进程可能会在“参数被安全检查”之后,而在实际使用之前,将参数换掉,这边使节或系统调用时所作的参数检查变得没有意义。但要解决这个问题,也不能仅把目光盯住系统的调用入口。

针对系统调用的过滤,不是一种沙箱的模式,其更多的提供了减少内核暴露的表面,除此之外,需要和其他的规则和方案进行配合。
当seccomp模式被添加,但它们不是直接设置超时的过程,是一种新的模式, 仅当CONFIG_SECCOMP_FILTER设置,并用prctl启用PR_ATTACH_SECCOMP_FILTER参数。
与seccomp过滤器交互式通过prctl调用。
PR_ATTACH_SECCOMP_FILTER ,允许一个新的过滤器使用BPF程序的规范,BPF程序将被执行user_regs_struct结构的数据。用法为

Linux系统安全_Sandbox

Sandbox沙箱在计算机领域中是一种程序隔离的机制,其目的则是限制不可信进程的权限。沙箱技术则常用于执行未经测试的或不可信的客户程序,(比如沙箱杀毒一类的),为了避免不可信程序可能破坏其他的程序运行,沙箱技术可以为不可信的程序提供虚拟化的磁盘,内存以及网络资源,而这又是对客户是透明的。

常规的安全机制则主要以降权来解决问题,但降权并不能带来真正的安全,sandbox也不能带来全方位的安全,沙箱机制结合多种系统安全技术来实现安全,从设计的理念上,打破传统的单一防御到纵深防御。

常规的纵深防御有六种常见的手法:

1 安全的编码(Secure Code),减少编写的错误。

2 应用技漏洞缓解技术(Application-level exploitation)(SSP,relro)

3 系统级漏洞缓解技术(System-level exploit mitigation)(ASLR,NX),

4 降权处理(Privilege Dropping)(Sandboxing)

5 强制访问控制(Mandatory access control)(MAC,SELinux)

6 更新策略(Update strategy)

 

进程和权限

         1 每个进程拥有独自的地址空间

         2 MMU硬件强制分离地址空间

         3 内核在系统中有强制性的接口层(kernel的安全策略)

         4 每个进程拥有进程权限边界

         5 root用户拥有至高的权限

         6 其他用户拥有自主访问控制DAC访问权限

一般情况下的权限控制为:

         进程A拥有的权能比进程B拥有的多,则A可以获得B进程可以访问的资源

         1 root用户运行任何程序都是特权用户

         2 2个进程如果拥有相同的uid,和gid。则可以拥有相同的权限

         3 一般不能比较不同uids用户的进程权限

进程和权限的分离

         1 线程

                   将内部特权进行分离(一般情况下)如NaCI,SECCOMP Sandbox

         2 Debugging

                 如果A进程可以Ptrace()B,那么A的权限要大于B的权限

 

 Linux标准的权限资源有

         1 Users,和 groups

                   1 uid,euid,suid,fsuid

                   2 gid,egid,sgid,fsgid,超级组

         2 POSIX.1e 权能

         3 Quota control

         4 Linux Container

         5 LSM(Linux Security Module)

 

Linux的权能划分了不同的权限单位

         如:CAP_NET_RAW: 允许使用RAW和PACKET Socket

                   CAP_SYS_ADMIN: 管理员操作权能(mount,sethostname等)

                   CAP_NET_BIND_SERVICE:bind绑定端口权限<1024

 

 权能的限制

         1 常见的误区:

                   1 忘记切换uid 为0的超级用户。很多功能需要root用户的权能

         2 root 操作

                   1 只有用到root权能的时候,才将权限提升为root权限

                   2 很多操作只需普通用户的权能。

使用切换root

1         需要对文件系统进行权限控制的时候,需要root用户

2         只有root可以操作的活动

3         需要一些陷入或escape的权限时,需要流行的chroot技术。

4         模块注入 非chroot进程的ptrace()

 

新的命名空间(Namespaces:CLONE_NEW*)

         CLONE_NEWPID: New pid namespace(2.6.24)

         CLONE_NEWNET:New network namsespace(2.6.26)

         CLONE_NEWIPC,CLONE_NEWUTS,CLONE_NEWNS(2.6.19)

 

资源限制

         为了安全的资源限制机制

         1 RLIMIT_NOFILE:不能获得新的句柄,但可以rename或者unlink

         2 RLIMIT_NPROC: 不能创建新的进程

         如果为了安全,RLIMIT_NPRC需要设置为(0,0),因为一些攻击者可以替代已经存在的句柄去创建新的socket或者文件句柄。

 

Dumpable(Debuggable)进程

         Linux支持对每个进程进行dumpable标志。

          通过PR_SET_DUMPABLE标记设置prctl,跟踪执行你没有权限的程序,或者切换uid。

          一个进程没有CAP_SYS_PTRACE权能,是不能ptrace非dumpable的进程

         需要一个进程权限提升或者可以降低其他进程的权限来满足dumpable。

 

MAC强制的访问控制

         在内核机制中,基于LSM钩子的有,SELInux,SMACK,TOMOYO

         内核机制之外的有:GRSecuirty, RSBAC, AppArmor

 

Sandbox 采取权限限制的策略

Sandbox与MAC的区别

         MAC需要管理员去分发布商。每个程序需要一套单独的规则库,不需要对代码的控制权

         Sandbox则是面向开发者,每个程序可以运行在多个设备上,不要要设备管理员的权限

 

常见的sandbox的设计:

         1 ptrace() sandbox (vsftpd)

         2       setuid sandbox(chromium)

         3      SECCOMP sandbox(chromium)

1 ptrace 架构:

setuid sandbox

 setuid sandbox基于Linux Kernel 所提供的安全机制如DAC实现,利用了uid/gid +  chroot()+capability的组合来达到目标,实现起来相对较为简单。

         传统的root 很难避免以下问题:1 需要对文件系统删除的访问2 RLIMIT_NOFILE 不够时的处理3  防止其他进程ptrace 4阻止信号发送给其他进程。

(一) Setuid :

利用uid的切换工作:

1我们需要获取uid/gid的定义池,但不需要资源/etc/passwd

2调用时,搜索到未用的uid/gid.然后切换到这个uid/gid

3执行sandbox。

Linux uid/gid 机制主要是用于进程的权限隔离,当你要执行不可信的程序时,那么在启动该程序的时,为其分配一个random uid。然后设置setuid。工作流程如下

Fork() ->setuid()->{设置相关的进程资源限制,如RLMIT_NPROC(0,)}->execve();

Setuid() 需要root的权限(或者具有CAP_SETUID 权能)才能调用成功。

 

(二) Chroot:

chroot 是 linux kernel 的另一个安全功能,他主要用于修改进程的根目录,比如执行chroot(“/tmp/sandbox/1”)则可以将当前进程的根目录切换为”/tmp/sandbox/1”。那么该进程的文件操作权限则被限制在当前目录下。

Chroot需要root权限(或者具有CAP_SYS_CHROOT权能)才能调用成功。

如果按照前面执行的顺序,具有root权限的进程A去执行chroot,然后再调用setuid,->..->execve(),这样是不可以的,因为execve所执行的路径已经发生改变,可执行文件已经不存在了。

Chris Evans的文章给了一个解决方法:

 

对A程序来说,由于它是以Root身份运行,那么就可能作为攻击点,比如confuesed deputy问题。下面针对这个问题加以说明。

 

(三) Linux Capability

 主要解决confused deputy问题,这个问题典型的代表是跨站点请求伪造(CSRF)。

Linux支持Capability的主要目的则是细化root特权,避免confused deputy问题。比如ping这个命令,需要raw_sockets,所以需要root的权限才可以运行,如果有了Capablity机制,该程序只要一个CAP_NET_RAW的权能,便可以运行,根据最小权限原则,该程序可以去掉所有不必要的权能。

当前kernel支持的权能多大30多种。在kernel2.6.24以后,普通用户也具有了capability.

 

Setuid sandbox简单易行,在google chromuim  早期的沙箱机制中使用了它,但现在已经默认为seccomp机制了。利用ipc机制创建socket pair

Seccomp

Seccomp 是 Andrea Arcangeli在2005年设计的,其目的则是解决 grid computer中的安全问题,比如你打算租借cpu资源,但又担心不可信的代码会破坏你的系统,那么seccomp

则为你提供了一个“安全(SAFE,not SECURE)”的环境。

         内核从2.6.10开始引入seccomp机制,该机制限制系统调用为read(),write(),exit(),sigreturn(). 只有4个系统调用被允许,相对较为简单,其限制了不能分配内存,不能共享内存, 不能创建新的文件描述符。成为了一个纯计算型的代码。

  运行在seccomp机制下的线程成为可信线程,当不可信的线程请求可信线程进行系统调用时,可信线程验证后方可进行调用。可信线程也只能使用只读的存储器,不能读取可变的区域。

有人提出了对seccomp机制的改进,利用bitmap增加一个新的mode,来限制使用那些权能。

通过截获系统调用来实现sandbox是一贯的做法,在现在的操作系统中,用户空间和内核空间是隔离的,一个进程只能通过系统调用才能从用户空间进入内核空间,如果一个进程不执行系统调用,那么被攻击的风险便会降低。当然,不调用系统调用是不切合实际的。

针对chromium使用的sandbox机制,我们将接下来进行分析。

WEB安全_浏览器安全_sandbox

  浏览器SandBox

google chrome 是一个采取多进程架构的浏览器,主要进程分为:浏览器内核进程,渲染引擎进程,插件进程,扩展进程等。这里针对google 开源chromuim进行说明。

Chromium允许渲染进程运行在Sandbox里,这样即便代码存在漏洞被网页利用了,也不会对系统造成威胁。

关于sandbox的安全机制,伯克利和斯坦福大学的研究学者们做了一个很好的论文,下面就泛泛的结合他们的论文谈一下。他们的论文题目为:《The Security Architecture of the Chromium Browser

》。

chromium 拥有2个模块来保护域安全,

browser kernel:其是和操作系统交互的。

rendering engine 渲染引擎,在沙箱中运行,限制权限。

1 简介

浏览器内核模块的行为代表用户,而渲染引擎模块代表网页,模块运行在单独的保护域,通过执行沙箱,降低了渲染引擎的权限。即使攻击者利用未修补漏洞的渲染引擎,获得整个渲染引擎沙箱的特权,也可以防止攻击者读写用户的文件系统

浏览器的安全策略,像同源策略一样复杂,可以说这种细粒度的隔离难以不破坏现有的网站,用户又要求其兼容性,为了兼容,一个模块化的浏览器必须要支持整个网络的平台。

浏览器的内核是负责管理持久性的资源,如cookie ,password database;以及用户和操作系统交换,接收用户的输入,并绘制到屏幕上,这个架构是基于以下2点的设计:

1)   该体系架构必须要兼容现有网络,具体而言,安全性限制网站的结构应该是透明的,这样的设计决策,极大的限制了整个体系结构的范畴。

2)    该体系结构将渲染引擎作为黑箱,将未解析的HTML作为输入,并将产生位图输出,尤其是该体系架构依赖于渲染引擎来执行同源策略,这样的设计降低了浏览器内核安全监控的复杂性,因为浏览器内核只需要执行粗粒度的安全增强便可以,例如,浏览器内核赋予对上传整个实例到渲染引擎的能力,这种特权值只需要单个的安全 “源”,

这种架构不能防止攻击者妥协渲染引擎从而攻击其他站点,(如读取其cookie);相反,该结构体的目的是房子读写用户的文件系统,从而帮助用户避免恶意软件侵袭。

为了评估chromium的安全性,我们选取离开IE,Firefox,Safari的漏洞统计,来确定那些漏洞会影响到chromium,发现其中67%的会发生在渲染引擎的地方。

chromium的体系结构为了减轻严重漏洞的危险,重新严格限定了攻击者使用浏览器内核的接口。测试了代码执行的漏洞会发生在浏览器内核中,其中72.7%的漏洞会利用充分验证的系统调用,而不是减轻了附加的沙箱。如,利用一个不当转义的Shell Execute弱点去攻击浏览器的外部协议。虽然这些弱点的统计不是很完善,但这些结果,让我们相信chromium的体系结构,适当的划分l浏览器内核和渲染引擎的浏览器组件。

     将浏览器分为2个保护区域,一个表示用户而另一个则是网页,chromium的安全体系架构可以减轻月70%的浏览器关键漏洞和攻击者执行的代码,其余的漏洞则归为沙箱来处理,这样架构可以充分利用沙箱的安全优势,又能够保持性能和现有的web的兼容性。

     首先采取的是三管齐下的措施来考量其兼容性,首先是通过完成99%的10115次兼容webkit的测试,第二人工访问了500个最为流行的网站来发现其不兼容性,第三通过已经部署的上以百万的用户反馈。

2威胁模型

为了表示chromium的安全属性,我们定一个枚举攻击者的能力和目标威胁模型,这个安全体系结构旨在防止攻击者为了达到目标所拥有的能力,我们可以利用这个威胁模型来评价chromium的架构如何有效的保护用户免受攻击。

(一)hacker的能力:我们认为攻击者知道一个未打补丁的安全漏洞在用户的浏览器上,并能够利用用户的浏览器渲染恶意的内容,通常,这些能力足够威胁用户的及其,更为具体的说,我们假设攻击者具备以下能力:

1)   攻击者拥有一个域名,如attacker.com 。这个域名还未添加到浏览器的恶意软件的黑名单中,攻击者拥有一个有效的https的证书域,并在网络上控制至少一台主机。具备这些能力只需5美元

2)   攻击者可以说服用户访问他的网站,这是很难的价格来衡量这种能力,但在以前的研究中,能吸引一季度100万用户只需要50美元左右

3)   攻击者利用利用一些exploit,攻击一些未打补丁的可以执行任意代码漏洞的用户浏览器,如HTML解析器的缓冲区溢出,正则表达式库的证书溢出,或书签的缓冲区溢出。

(二)范围内目标,chromium架构侧重于防止攻击者从三个高度实现目标:

1)   持续的恶意软件,攻击者试图在用户计算机上安装恶意软件,如:安装一个僵尸网络的客户端,接收命令,在网络中工作或协同其他用户参与网络工作。

2)   键盘记录器,攻击者监视用户的击键,用来盗取用户密码和隐私数据。需要在用户没有关闭浏览器才能生存。

3)   文件盗取,攻击者企图获取用户磁盘上的敏感数据

如果攻击者能够实现这些目标的一个或多个,将会给用户造成严重的危害,chromium的体系架构目的是防止攻击者的这种能力

三) 范围外的目标,有很多攻击者的目标是chromium体系机构不提供的额外保护,chromium包含一定的特性低于这些危险,这些特性依赖渲染引擎执行的”同源策略”

1)   网络钓鱼,在钓鱼攻击中,攻击者使用一些技巧让用户进入一个不城市的网站,并提供了自己的密码。攻击者利用未修补的漏洞可以创建一个说服钓鱼网站破坏一个窗口显示真实的网站。

1)chromium具备多项安全功能减轻网络钓鱼攻击,浏览器突出显示网站域名,已知钓鱼网站的安全警告,以及额外的安全性用户界面元素。

2)   “源隔离” chromium的架构 渲染引擎将会对整个网络站点为主进行渲染,意味这渲染引擎可以代表整个网站,例如,攻击者利用代码执行漏洞获得cookie,存储在浏览器内密码,如果攻击者不能利用这些未修补的漏洞,通常浏览器的安全策略防止攻击者读取coolie或密码,主机名不在他的控制下。

3)   防火墙规避,同源策略是限制攻击者的访问是在浏览器内,防火墙规避旨在保护机密资源。

4)    网站的漏洞,如果网站包含xss,csrf,以及header注入等,这些需要网站必须修复其脆弱性。 chromium支持httpOnlyCookies来缓解部分XSS

3 chromium架构

 

chromium结构有2个模块,渲染引擎和浏览器内核,在一个较高的水平,渲染引擎负责转换HTTP响应和用户输入事件转换为呈现的位图,而浏览器内核则负责用户操作系统进行交互,内核的浏览器公开API,渲染引擎使用网络发出请求,访问持久化存储,并显示在用户的屏幕上的位图。浏览器内核是值得用户信任的,而渲染引擎则是值得网页信任的。

(一) 渲染引擎,渲染引擎解释执行网页内容提供的默认行为,如绘制<input>元素,和服务调用DOM API,呈现的网页进行了几个阶段,1 开始与解析,建立一个在内存的DOM表示,奠定了图形化的文件和操作文件,解析脚本指令,渲染引擎也负责限制同源策略,着有助于防止恶意网站中断用户和真实的网站会话。

                                                              (表1)

      渲染引擎         

      浏览器内核

      HTML 解析     

  cookie数据库

      CSS 解析        

      历史访问数据库

      图像解码         

      密码数据库

      js解释器         

      窗口管理

      正则表达式      

      地址栏

      布局               

      安全浏览黑名单

      文档对象模型   

      网络协议栈

      渲染             

      SSL/TLS

      SVG               

   磁盘缓存

      XML解析        

      下载管理

      XSLT              

      剪贴板

BOTH

URL 解析

unicode解析

(一)渲染引擎,包含拉大部分浏览器的复杂性和佳和最直接的与不可信网页内容,例如大多数的解析发生在渲染引擎,包括HTML解析,图像解码,js解析。为了与用户,本地主机,网络交互,渲染引擎使用了浏览器内核的API,渲染引擎运行在操作系统限制的沙箱中。

(二)浏览器内核,浏览器内核负责管理多个实例的渲染引擎和实施的浏览器内核API,例如,浏览器内核实现了基于选项卡的窗口系统,包括地址栏,显示当前处于获得的URL选项卡,及其相关的安全指标,浏览器内核管理的持久化状态,如用户的书签,cookie,并保存密码,它还负责与网络进行交互与渲染引擎与操作系统的原生窗口管理器之间的中介,为了实现它的API,浏览器内核维护状态信息的权限,并据此向每个渲染引擎,如允许上载文件的列表的每个渲染引擎,浏览器内核使用这些安全策略防止渲染引擎被攻破后与用户操作系统的隔离。

驱动的浏览器组建分配的任务还有一些是为了兼容性遗留的,比如浏览器内核负责js alert警告,select下拉菜单则有渲染引擎, 某些功能,如cookie数据库还是有浏览器内核实现的,因为它直接访问文件系统,正则表达式则有渲染引擎来实现,因为他对性能是敏感的,而且有常见的安全漏洞。

正如表1所示,渲染引擎负责对于大多数的分析和加密,因为历史上,这些任务已经发生大量的源漏洞,例如,要显示一个网站的快捷图标,在浏览器用户界面,浏览器内核网络检索图像,但并不实体进行解码,相反,浏览器内核发送图像用于解码的渲染引擎,渲染引擎响应一个未压缩的图标的位图,其中浏览器内核将其复制到屏幕上,这个看似复杂的步骤,有助于防止攻击者利用一个未修补的图像解码器漏洞控制浏览器内核。这种模式的一个例外是网络协议栈,HTTP协议栈是负责解析HTTP响应头和调用gzip或bzip2解码器解压缩,这些内容编码HTTP响应,这些任务分配给渲染引擎,在成本上复杂的网络堆栈和降低性能。而URL需要浏览器内核和渲染引擎都去解析,因为URL处理无处不在。

(三)进程粒度:粗略的说,chromium使用一个单独的实例为每个标签开启一个渲染引擎,显示的内容从网页,在渲染引擎崩溃的情况下提供容错。使用渲染引擎提供受信证书的解析,如HTTPS 证书错误的警告,然而,这些渲染任务是有一个单独实例的渲染引擎,不处理从网络上获得的内容。主要的里外这种模式是web检测器,他显示信任呈现的内容和有渲染引擎显示的网页,chromium采用这种设计,因为WEB检测器交互广泛的页面检查。

插件 – chromium的架构中,每个插件运行在一个单独的主机进程中,单独于渲染引擎和浏览器内核,为了兼容现有网站,浏览器插件无法在渲染引擎里运行,因为供应商期望插件最多有一个实例的插件在web 浏览器。如果插件驻留在浏览器内核,插件的崩溃,就足够崩溃了整个浏览器。在默认的情况下,每个插件运行在沙箱以外,而且用户具有完全访问的权限,这个设置将保持现有的插件和网站,因为插件可以有任意行为,如flash 播放器插件可以控制用户的microphone和webcam,以及用户的文件系统,此设置的限制是,攻击者可以利用未修补的插件漏洞在用户计算机上安装恶意软件,供应商可以写入chromium的sandbox,能为用户提供更到范围的防外挂攻击,chromium还有一个选项,以现有的插件在sandbox中运行,要做到这一点,chromium提供一些安全设置,–safe-plugins 在命令行中设置。此设置只是实验性的,可能导致不稳定或以外现象

4沙箱

 

为了帮助抵御攻击者利用一个chromium渲染引擎的弱点,每个渲染引擎都在sandbox中,sandbox限制了渲染引擎的在运行过程中的系统调用,这些系统调用可以帮助用户达到目标。

(一)目标: 在理想状态下,sandbox会迫使渲染引擎使用浏览器内核的API与外界进行交互,许多DOM方法,如appendChild方法。在渲染引擎中实现简单的状态改变以及完全改变,在DOM方法中,XMLHttpRequest方法需要渲染引擎做的不仅仅是内部状态,一个可信的渲染引擎可以使用浏览器内核的接口来实现这些方法,sandbox目标是需要一个妥协的渲染引擎来使用浏览器内核与用户和文件系统交互。

(二)实现:当前,chromium的特定功能-sandbox渲染引擎,为了替代基于windows安全口令的方法,渲染引擎使用了Restricted Token的安全令牌的方法。每当渲染引擎试图访问一个安全对象时,Windows安全管理器会检查渲染引擎的安全令牌是否有足够的权限访问该对象。sandbox这种严格限定渲染引擎安全引擎的安全检测方法几乎在每一次这样的访问中。

(三)在渲染web协议栈。渲染引擎调整其进程的安全令牌,将安全标示符SID设置为DENY_ONLY,并添加一些严格的SID和调用AdjustTokenPrivileges函数。渲染引擎一样可以运行在一个单独的桌面中,以用来减轻安全性检查不严的WINdows API。如 调用 SetWindowsHookEx,限制一些有用无安全问题的对象,如 HWND_BROADCAST,这些目前仅限于桌面。此外,渲染引擎在windows作业对象上,限制了渲染引擎创建进程,读写剪贴板,访问用户处理的能力。

四) 限制: 虽然sandbox 限制和妥协渲染引擎交互操作的一些能力,但sandbox本身还有一些限制

1)   FAT32: fat32不支持访问控制列表,没有访问控制列表,windows的安全管理器会忽略进行的安全令牌。

2)   错误的配置对象:如果一个对象有一个NULL DACL(Discretionary access control list),在windows 安全管理器将授予访问权限,而不考虑访问的安全性令牌,虽然NULL DACL是涵见的,但一些第三方应用程序会创建NULL DACL对象,在NTFS文件系统中,问题大大减少,因为这种限制在沙箱中的删除权限,“跳过安全遍历”,迫使windows渲染引擎能够访问到目标文件的父目录。

3)TCP/IP 理论上讲,渲染引擎在Windows XP创建一个SOCKET 套接字,因为低级别的系统调用打开一个套接字,不需要操作系统执行访问检查,然而,通常win 32为库函数在创建套接字时失败,因为这些API是渲染引擎无法捕获的。我们试图建立一个POC(Proof-of-concept),在sandbox中进程无法打开套接字。在Vista中,有关的系统调用会执行安全访问检测,

 5 浏览器内核接口

 

sandbox渲染引擎限制直接与底层操作系统交互的能力。如用户交互持续性存储和网络,渲染引擎依赖与浏览器内核的API,在提供函数给渲染浏览器功能时,一定要仔细设计不授予没有必要的权限,特别是浏览器内核不能设计成泄漏读写用户文件系统的能力。

(一)用户交互: 操作系统交互的接口,允许应用程序与用户进行交互,但这些接口没有设计要使用不受信任的程序,如 X windows 系统,以创建一个窗口的 X server,意味着监视所以用户的击键,浏览器内核是渲染引擎的中介,以协助执行2个安全约束与用户互动。

1)   渲染。不是给与渲染引擎直接访问一个窗口的句柄,渲染引擎引入一个离屏位图。要显示位图给用户,渲染引擎发送的位图给浏览器内核,浏览器内核复制位图到屏幕上。这种设计增加拉一个单独的屏幕,如一般的绘图到屏幕是通过内存拷贝到内存管道,其中有一个类似的双缓冲性能的影响,以及所呈现的位图浏览器窗口的内存区域。

2)   用户输入,而不是传送用户输入直接到渲染引擎,操作系统提供这事件给浏览器内核,浏览器内核调度这些事件定位当前用户界面元素。如果焦点在chrome浏览器上,输入事件则有浏览器内核处理,如果该内容具有焦点时,浏览器内核将输入时间交个渲染引擎,本设计利用用户的焦点来限制用户的输入事件给渲染引擎。

(二)持久性存储:sandbox的责任是确保渲染引擎的责任是不能直接访问用户的文件系统。然而,渲染引擎不需要一些用户的文件上传和下载

1)   上传,用户可以将文件上传到网站,需要上传控制,当用户点击表单控件,浏览器显示一个文件选择的对话框,让用户选择上传的文件,如果浏览器内核不限制文件,渲染引擎可以直接上传,攻击者利用渲染引擎便会读取用户文件系统的文件

chromium采用了类似DarpaBrowser的powerbox模式,处理用户的选择,授权到同一个文件选择对话框的文件上传文件到任意网站,浏览器内核负责显示文件对话框和记录文件的用户已授权渲染引擎的历史,同样当文件拖放到浏览器的内容,渲染引擎积极渲染上传的授权文件。

2)   下载,当下载文件时,一个网站允许写入到用户的文件系统,不是直接的写入文件系统,而渲染引擎使用浏览器内核的API下载,为了保护文件系统,浏览器内核下载到指定的下载目录,此外浏览器内核黑名单的某些文件名,渲染引擎可以用它来提升权限检测,如设备名,文件名,本地扩展,shell集成的文件名,如:desktop.ini

(三) 网络 而不是直接访问,渲染引擎检索通过浏览器内核从网络中检索URL,在一个URL请求提供服务,渲染引擎检查浏览器内核是否授权的URL,网络的URL协议如http,https,FTP,可以请求每个实例的渲染引擎。浏览器内核防止大多数渲染引擎请求URL的方案,因为一个有漏洞的渲染引擎可以读取用户磁盘驱动器的各种文件的URL。

6 chromuim 源代码下载

 

获得chromuim源代码的方法如下:

           1 安装gclient工具:

获得 depot_tools:git:

添加depot_tools 路径 PATH:$ export PATH=”$PATH”:pwd/depot_tools

也可以添加到. bashrc 文件中。

2) 下载代码

7 chromuim 源代码举例

以上是POC的一段代码,由于分析代码不是本文的主题,这里就不深究下去了,此章只是想让大家了解浏览器安全的问题。
除了上面的安全问题,还有恶意网址拦截等安全问题,这里就不再分析下去了