mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-12 01:40:10 +08:00
Merge branch 'master' of https://github.com/LCTT/TranslateProject
This commit is contained in:
liaoishere
commit
ca450ff5f3
@ -1,49 +0,0 @@
|
||||
Traslating by H-mudcup
|
||||
|
||||
U.S. Marine Corps Wants to Change OS for Radar System from Windows XP to Linux
|
||||
================================================================================
|
||||
**A new radar system has been sent back for upgrade**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
> When it comes to stability and performance, nothing can really beat Linux. This is why the U.S. Marine Corps leaders have decided to ask Northrop Grumman Corp. Electronic Systems to change the operating system of the newly delivered Ground/Air Task-Oriented Radar (G/ATOR) from Windows XP to Linux.
|
||||
|
||||
The Ground/Air Task-Oriented Radar (G/ATOR) system has been in the works for many years and it's very likely that when the project was started, Windows XP could have been considered the logical choice. In the mean time, things changed. Microsoft has pulled the support for Windows XP and very few entities still use it. The operating system is either upgraded or replaced. In this case, Linux is the logical choice, especially since the replacement cost are probably much smaller than an eventual upgrade.
|
||||
|
||||
It's interesting to note that the Ground/Air Task-Oriented Radar (G/ATOR) was just delivered to the U.S. Marine Corps, but the company that built it chose to keep that aging operating system. Someone must have noticed the fact that it was a poor decision and the chain of command was informed of the problems that might have appeared.
|
||||
|
||||
### G/ATOR radar software will be Linux-based ###
|
||||
|
||||
Unix systems, like BSD-based or Linux-based OSes, are usually found in critical areas and technologies that can't fail, under any circumstances. That's why most of the servers out there are running Linux servers, for example. Having a radar system with an operating systems that is very unlikely to crash seems to fit the bill perfectly.
|
||||
|
||||
"Officials of the Marine Corps Systems Command at Quantico Marine Base, Va., announced a $10.2 million contract modification Wednesday to the Northrop Grumman Corp. Electronic Systems segment in Linthicum Heights, Md., to convert the Ground/Air Task-Oriented Radar (G/ATOR) operator command and control computer from Windows XP to Linux. The contract modification will incorporate a change order to switch the G/ATOR control computer from the Microsoft Windows XP operating system to a Defense Information Systems Agency (DISA)-compliant Linux operating system."
|
||||
|
||||
'G/ATOR is an expeditionary, three-dimensional, short-to-medium-range multi-role radar system designed to detect low-observable targets with low radar cross sections such as rockets, artillery, mortars, cruise missiles, and UAVs," reads the entry on [militaryaerospace.com][1].
|
||||
|
||||
This piece of military technology, the Ground/Air Task-Oriented Radar (G/ATOR) was first contracted from the Northrop Grumman Corp. back in 2005, so it's easy to understand why the US Marines might want to hurry this up. No time frame has been proposed for the switch.
|
||||
|
||||
视频链接：[http://youtu.be/H2ppl4x-eu8][2]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://news.softpedia.com/news/U-S-Marine-Corps-Want-to-Change-OS-for-Radar-System-from-Windows-XP-to-Linux-466756.shtml
|
||||
|
||||
作者：[Silviu Stahie][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://news.softpedia.com/editors/browse/silviu-stahie
|
||||
[1]:http://www.militaryaerospace.com/articles/2014/12/gator-linux-software.html
|
||||
[2]:http://youtu.be/H2ppl4x-eu8
|
||||
@ -1,3 +1,5 @@
|
||||
Translating by H-mudcup
|
||||
|
||||
Flow ‘N Play Movie Player Has a Stylish Interface [Ubuntu Installation]
|
||||
================================================================================
|
||||
**Flow ‘N Play** is a new video player written in Qt which features a pretty slick and simple interface which provides only the basic features for playing movies.
|
||||
|
||||
132
sources/tech/20150104 Docker Image Insecurity.md
Normal file
132
sources/tech/20150104 Docker Image Insecurity.md
Normal file
@ -0,0 +1,132 @@
|
||||
Docker Image Insecurity
|
||||
================================================================================
|
||||
Recently while downloading an “official” container image with Docker I saw this line:
|
||||
|
||||
ubuntu:14.04: The image you are pulling has been verified
|
||||
|
||||
I assumed this referenced Docker’s [heavily promoted][1] image signing system and didn’t investigate further at the time. Later, while researching the cryptographic digest system that Docker tries to secure images with, I had the opportunity to explore further. What I found was a total systemic failure of all logic related to image security.
|
||||
|
||||
Docker’s report that a downloaded image is “verified” is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest. An attacker could provide any image alongside a signed manifest. This opens the door to a number of serious vulnerabilities.
|
||||
|
||||
Images are downloaded from an HTTPS server and go through an insecure streaming processing pipeline in the Docker daemon:
|
||||
|
||||
[decompress] -> [tarsum] -> [unpack]
|
||||
|
||||
This pipeline is performant but completely insecure. Untrusted input should not be processed before verifying its signature. Unfortunately Docker processes images three times before checksum verification is supposed to occur.
|
||||
|
||||
However, despite [Docker’s claims][2], image checksums are never actually checked. This is the only section[0][3] of Docker’s code related to verifying image checksums, and I was unable to trigger the warning even when presenting images with mismatched checksums.
|
||||
|
||||
if img.Checksum != "" && img.Checksum != checksum {
|
||||
log.Warnf("image layer checksum mismatch: computed %q,
|
||||
expected %q", checksum, img.Checksum)
|
||||
}
|
||||
|
||||
### Insecure processing pipeline ###
|
||||
|
||||
**Decompress**
|
||||
|
||||
Docker supports three compression algorithms: gzip, bzip2, and xz. The first two use the Go standard library implementations, which are [memory-safe][4], so the exploit types I’d expect to see here are denial of service attacks like crashes and excessive CPU and memory usage.
|
||||
|
||||
The third compression algorithm, xz, is more interesting. Since there is no native Go implementation, Docker [execs][5] the `xz` binary to do the decompression.
|
||||
|
||||
The xz binary comes from the [XZ Utils][6] project, and is built from approximately[1][7] twenty thousand lines of C code. C is not a memory-safe language. This means malicious input to a C program, in this case the Docker image XZ Utils is unpacking, could potentially execute arbitrary code.
|
||||
|
||||
Docker exacerbates this situation by *running* `xz` as root. This means that if there is a single vulnerability in `xz`, a call to `docker pull` could result in the complete compromise of your entire system.
|
||||
|
||||
**Tarsum**
|
||||
|
||||
The use of tarsum is well-meaning but completely flawed. In order to get a deterministic checksum of the contents of an arbitrarily encoded tar file, Docker decodes the tar and then hashes specific portions, while excluding others, in a [deterministic order][8].
|
||||
|
||||
Since this processing is done in order to generate the checksum, it is decoding untrusted data which could be designed to exploit the tarsum code[2][9]. Potential exploits here are denial of service as well as logic flaws that could cause files to be injected, skipped, processed differently, modified, appended to, etc. without the checksum changing.
|
||||
|
||||
**Unpacking**
|
||||
|
||||
Unpacking consists of decoding the tar and placing files on the disk. This is extraordinarily dangerous as there have been three other vulnerabilities reported[3][10] in the unpack stage at the time of writing.
|
||||
|
||||
There is no situation where data that has not been verified should be unpacked onto disk.
|
||||
|
||||
### libtrust ###
|
||||
|
||||
[libtrust][11] is a Docker package that claims to provide “authorization and access control through a distributed trust graph.” Unfortunately no specification appears to exist, however it looks like it implements some parts of the [Javascript Object Signing and Encryption][12] specifications along with other unspecified algorithms.
|
||||
|
||||
Downloading an image with a manifest signed and verified using libtrust is what triggers this inaccurate message (only the manifest is checked, not the actual image contents):
|
||||
|
||||
ubuntu:14.04: The image you are pulling has been verified
|
||||
|
||||
Currently only “official” image manifests published by Docker, Inc are signed using this system, but from discussions I participated in at the last Docker Governance Advisory Board meeting[4][13], my understanding is that Docker, Inc is planning on deploying this more widely in the future. The intended goal is centralization with Docker, Inc controlling a Certificate Authority that then signs images and/or client certificates.
|
||||
|
||||
I looked for the signing key in Docker’s code but was unable to find it. As it turns out the key is not embedded in the binary as one would expect. Instead the Docker daemon fetches it [over HTTPS from a CDN][14] before each image download. This is a terrible approach as a variety of attacks could lead to trusted keys being replaced with malicious ones. These attacks include but are not limited to: compromise of the CDN vendor, compromise of the CDN origin serving the key, and man in the middle attacks on clients downloading the keys.
|
||||
|
||||
### Remediation ###
|
||||
|
||||
I [reported][15] some of the issues I found with the tarsum system before I finished this research, but so far nothing I have reported has been fixed.
|
||||
|
||||
Some steps I believe should be taken to improve the security of the Docker image download system:
|
||||
Drop tarsum and actually verify image digests
|
||||
|
||||
Tarsum should not be used for security. Instead, images must be fully downloaded and their cryptographic signatures verified before any processing takes place.
|
||||
|
||||
**Add privilege isolation**
|
||||
|
||||
Image processing steps that involve decompression or unpacking should be run in isolated processes (containers?) that have only the bare minimum required privileges to operate. There is no scenario where a decompression tool like `xz` should be run as root.
|
||||
|
||||
**Replace libtrust**
|
||||
|
||||
Libtrust should be replaced with [The Update Framework][16] which is explicitly designed to solve the real problems around signing software binaries. The threat model is very comprehensive and addresses many things that have not been considered in libtrust. There is a complete specification as well as a reference implementation written in Python, and I have begun work on a [Go implementation][17] and welcome contributions.
|
||||
|
||||
As part of adding TUF to Docker, a local keystore should be added that maps root keys to registry URLs so that users can have their own signing keys that are not managed by Docker, Inc.
|
||||
|
||||
I would like to note that using non-Docker, Inc hosted registries is a very poor user experience in general. Docker, Inc seems content with relegating third party registries to second class status when there is no technical reason to do so. This is a problem both for the ecosystem in general and the security of end users. A comprehensive, decentralized security model for third party registries is both necessary and desirable. I encourage Docker, Inc to take this into consideration when redesigning their security model and image verification system.
|
||||
|
||||
### Conclusion ###
|
||||
|
||||
Docker users should be aware that the code responsible for downloading images is shockingly insecure. Users should only download images whose provenance is without question. At present, this does *not* include “trusted” images hosted by Docker, Inc including the official Ubuntu and other base images.
|
||||
|
||||
The best option is to block `index.docker.io` locally, and download and verify images manually before importing them into Docker using `docker load`. Red Hat’s security blog has [a good post about this][18].
|
||||
|
||||
Thanks to Lewis Marshall for pointing out the tarsums are never verified.
|
||||
|
||||
- [Checksum code context][19].
|
||||
- [cloc][20] says 18,141 non-blank, non-comment lines of C and 5,900 lines of headers in v5.2.0.
|
||||
- Very similar bugs been [found in Android][21], which allowed arbitrary files to be injected into signed packages, and [the Windows Authenticode][22] signature system, which allowed binary modification.
|
||||
- Specifically: [CVE-2014-6407][23], [CVE-2014-9356][24], and [CVE-2014-9357][25]. There were two Docker [security releases][26] in response.
|
||||
- See page 8 of the [notes from the 2014-10-28 DGAB meeting][27].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://titanous.com/posts/docker-insecurity
|
||||
|
||||
作者：[titanous][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://twitter.com/titanous
|
||||
[1]:https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/
|
||||
[2]:https://blog.docker.com/2014/10/docker-1-3-signed-images-process-injection-security-options-mac-shared-directories/
|
||||
[3]:https://titanous.com/posts/docker-insecurity#fn:0
|
||||
[4]:https://en.wikipedia.org/wiki/Memory_safety
|
||||
[5]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/pkg/archive/archive.go#L91-L95
|
||||
[6]:http://tukaani.org/xz/
|
||||
[7]:https://titanous.com/posts/docker-insecurity#fn:1
|
||||
[8]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/pkg/tarsum/tarsum_spec.md
|
||||
[9]:https://titanous.com/posts/docker-insecurity#fn:2
|
||||
[10]:https://titanous.com/posts/docker-insecurity#fn:3
|
||||
[11]:https://github.com/docker/libtrust
|
||||
[12]:https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-11
|
||||
[13]:https://titanous.com/posts/docker-insecurity#fn:4
|
||||
[14]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/trust/trusts.go#L38
|
||||
[15]:https://github.com/docker/docker/issues/9719
|
||||
[16]:http://theupdateframework.com/
|
||||
[17]:https://github.com/flynn/go-tuf
|
||||
[18]:https://securityblog.redhat.com/2014/12/18/before-you-initiate-a-docker-pull/
|
||||
[19]:https://github.com/docker/docker/blob/0874f9ab77a7957633cd835241a76ee4406196d8/image/image.go#L114-L116
|
||||
[20]:http://cloc.sourceforge.net/
|
||||
[21]:http://www.saurik.com/id/17
|
||||
[22]:http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx
|
||||
[23]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6407
|
||||
[24]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9356
|
||||
[25]:https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9357
|
||||
[26]:https://groups.google.com/d/topic/docker-user/nFAz-B-n4Bw/discussion
|
||||
[27]:https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg/edit?pli=1
|
||||
@ -0,0 +1,49 @@
|
||||
Traslated by H-mudcup
|
||||
|
||||
美国海军陆战队想把雷达操作系统从Windows XP换成Linux
|
||||
================================================================================
|
||||
**一个新的雷达系统已经被送回去升级了**
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
>一谈到稳定性和性能，没什么能真的比得过Linux。这就是为什么美国海军陆战队的领导们已经决定让Northrop Grumman Corp. Electronic Systems把新送到的地面/空中任务导向雷达（G/ATOR）的操作系统从Windows XP换成Linux。
|
||||
|
||||
地面/空中任务导向雷达（G/ATOR）系统已经研制了很多年。很可能在这项工程启动的时候Windows XP被认为是合理的选择。在研制的这段时间，事情发生了变化。微软已经撤销了对Windows XP的支持而且只有极少的几个组织会使用它。操作系统要么升级要么被换掉。在这种情况下，Linux成了合理的选择。特别是当替换的费用很可能远远少于更新的费用。
|
||||
|
||||
有个很有趣的地方值得注意一下。地面/空中任务导向雷达（G/ATOR）才刚刚送到美国海军陆战队，但是制造它的公司却还是选择了保留这个过时的操作系统。一定有人注意到的这样一个事实。这是一个糟糕的决定，并且指挥系统已经被告知了可能出现的问题了。
|
||||
|
||||
### G/ATOR雷达的软件将是基于Linux的 ###
|
||||
|
||||
Unix类系统，比如基于BSD或者基于Linux的操作系统，通常会出现在条件苛刻的领域，或者任何情况下都不能失败的的技术中。例如，这就是为什么大多数的服务器都运行着Linux。一个雷达系统配上一个几乎不可能崩溃的操作系统看起来非常相配。
|
||||
|
||||
“弗吉尼亚州Quantico海军基地海军陆战队系统司令部的官员，在周三宣布了一项与Northrop Grumman Corp. Electronic Systems在林西科姆高地的部分的总经理签订的价值1020万美元的修正合同。这个合同的修改将包括这样一项，把G/ATOR的控制电脑从微软的Windows XP操作系统换成与国防信息局（DISA）兼容的Linux操作系统。”
|
||||
|
||||
‘G/ATOR是一个远征三维中短距离多用途雷达系统。这个系统被设计成能够探测拥有低雷达截面的低可观测目标，比如火箭弹，火炮，迫击炮，巡航导弹以及无人机。”这些内容可以在[militaryaerospace.com][1]看到。
|
||||
|
||||
这项军用科技，即地面/空中任务导向雷达（G/ATOR），早在2005年就与Northrop Grumman签订了第一次合同。所以不难理解为什么美国海军可能想把这件事快点弄完。这次更换的时间限制还没有被提议。
|
||||
|
||||
视频链接：[http://youtu.be/H2ppl4x-eu8][2]
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: http://news.softpedia.com/news/U-S-Marine-Corps-Want-to-Change-OS-for-Radar-System-from-Windows-XP-to-Linux-466756.shtml
|
||||
|
||||
作者：[Silviu Stahie][a]
|
||||
译者：[H-mudcup](https://github.com/H-mudcup)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:http://news.softpedia.com/editors/browse/silviu-stahie
|
||||
[1]:http://www.militaryaerospace.com/articles/2014/12/gator-linux-software.html
|
||||
[2]:http://youtu.be/H2ppl4x-eu8
|
||||
Loading…
Reference in New Issue
Block a user