| Author |
Message |
jheaton5
|
|
Post subject: Attack at kernel.org
 Posted: 09.09.2011, 13:49
|
|
Joined: 2010-09-18
Posts: 26
Status: Offline
|
|
|
|
|
 |
|
slam
|
|
|
Post subject: RE: Attack at kernel.org
Posted: 09.09.2011, 14:58
|
|
Team Member
Joined: 1970-01-01
Posts: 606
Location: w3
Status: Offline
|
|
We do not use Git for development of aptosid tools and kernel. Add, that we distribute signed binary packages and sources via our own signed repository. We take security very seriously also in several other areas (distributing our releases with secure pre-settings, iso files with checksums over trusted mirrors only, support focus on secure practice, etc.).
However, nothing will ever be 100% secure everywhere - after all, security is an ongoing process.
Greetings,
Chris |
_________________
an operating system must operate
development is life
my Debian repo
|
| |
|
|
|
|
|
jheaton5
|
|
|
Post subject:
Posted: 09.09.2011, 16:34
|
|
Joined: 2010-09-18
Posts: 26
Status: Offline
|
|
| I don't think it's an issue of using git locally. I think it's a question of the quality of source code from upstream that are used to compile the aptosid kernels. Surely you retrieve an updated kernel from either the debian repository or kernel.log. If you get it from debian repository don't they get it from kernel.log? The source of the problem is at the place where the kernel code is written that everyone uses to make their own custom kernels. |
|
|
| |
|
|
|
|
|
CaesarTjalbo
|
|
|
Post subject:
Posted: 09.09.2011, 19:32
|
|
Joined: 2010-09-13
Posts: 95
Location: Enschede
Status: Offline
|
|
|
jheaton5 wrote:
The source of the problem is at the place where the kernel code is written that everyone uses to make their own custom kernels.
True. The main worry of the admins should be how the attacker(s) gained root access in the first place and from there on verifying everything.
However, Git doesn't have to be the attack vector. Sure you want to have a solid control over Git and your procedures of working with it (because even in the case of Linus Torvalds, creator of both Linux and Git, the human is the weakest link) but that's not the issue here.
It's possible that there are inherent weaknesses in Git but unless it was through Git that the attacker(s) gained root access, any concerns about Git are secondary. |
|
|
| |
|
|
|
|
|
jheaton5
|
|
|
Post subject:
Posted: 09.09.2011, 23:17
|
|
Joined: 2010-09-18
Posts: 26
Status: Offline
|
|
|
CaesarTjalbo wrote:
The main worry of the admins should be how the attacker(s) gained root access in the first place and from there on verifying everything.
It was by acquiring control of H. Peter Anvin's computer that he gained a route into kernel.org. |
|
|
| |
|
|
|
|
|
jacmoe
|
|
|
Post subject:
Posted: 10.09.2011, 00:15
|
|
Joined: 2011-04-13
Posts: 40
Location: Denmark
Status: Offline
|
|
Use Mercurial. It rules.  |
|
|
| |
|
|
|
|
|
slam
|
|
|
Post subject:
Posted: 10.09.2011, 06:16
|
|
Team Member
Joined: 1970-01-01
Posts: 606
Location: w3
Status: Offline
|
|
|
jheaton5 wrote:
I don't think it's an issue of using git locally. I think it's a question of the quality of source code from upstream that are used to compile the aptosid kernels. Surely you retrieve an updated kernel from either the debian repository or kernel.log. If you get it from debian repository don't they get it from kernel.log? The source of the problem is at the place where the kernel code is written that everyone uses to make their own custom kernels.
We do not use the Debian kernels at all. The Aptosid kernel is a vanilla kernel, to which we ad series of patches together with our own configuration.
All revision control systems (cvs, svn, git, mercurial, etc.) are secure by design, because every single commit is saved, and can be reverted. So, whatever the "intruder" has done while using a kernel hackers pc can be repaired easily.
Greetings,
Chris |
_________________
an operating system must operate
development is life
my Debian repo
|
| |
|
|
|
|
|
DonKult
|
|
|
Post subject:
Posted: 10.09.2011, 08:27
|
|
Team Member
Joined: 2010-09-02
Posts: 417
Status: Offline
|
|
|
slam wrote:
All revision control systems (cvs, svn, git, mercurial, etc.) are secure by design, because every single commit is saved, and can be reverted. So, whatever the "intruder" has done while using a kernel hackers pc can be repaired easily.
Also, consider what is described in one of the in-deep articles: You not only need to trick the version control system into a commit, but you need to prepare a good answer for $kernelhacker who will push to his/her branch and gets a 'branches diverted' error…
I am not a kernelhacker, but i would be surprised if my personal branch suddenly contains commits i haven't authored…
All in all i couldn't care less for such a break-in. Okay, it's big news and the hacker can get a hard-on based on that, but in reality most if not all computer users face bigger security-attack-vector each day but don't care.
Many third-party repositories doesn't provide a signature for example. This is close to a formal invitation for Man-in-the-middle attacks in which the attacker can become root by answering the request with a manipulated package… The same is true for any download from the web in general which isn't checked for a valid trusted signature. A md5sum (or any other checksum) can only tell you that the file was correctly downloaded, but what if the website mentioning the md5sum was already manipulated by Mallory? And if we go the signature road: Are you sure that this key is really from the person it claims to be? You are sure because you have meet him/her in person to validate his key and id, right? (Assuming that nobody can fake an id…) Maybe you have friends who know him/her, then you might be lucky as they can guarantee his identity. If we assume that this is not a world-wide conspiracy against you of course…
Security is a dangerous field as at some point you have to trust someone as a base and you would better not trust Mallory, but how do you know for sure that he/she/it isn't Mallory… chicken or egg?
(both, well cooked and served with a bit of spinach, please) |
_________________
MfG. DonKult
"I never make stupid mistakes. Only very, very clever ones." ~ The Doctor
|
| |
|
|
|
|
|
jheaton5
|
|
|
Post subject:
Posted: 10.09.2011, 12:17
|
|
Joined: 2010-09-18
Posts: 26
Status: Offline
|
|
|
slam wrote:
We do not use the Debian kernels at all. The Aptosid kernel is a vanilla kernel, to which we ad series of patches together with our own configuration.
Thank you for your time in explaining this to me. My concern is not with your kernel building process. You guys certainly know what you are doing.
My concern is what is going on at kernel.org. The original PR announcement said "not to worry all will be well in a few days." Then they shut down their servers and they have been down now for 20+ days. The computer that was compromised was one belonging to H. Peter Anvin, one of the pioneer members of the kernel team. There have been no more PR statements. All is quiet at kernel.org. Obviously the problem is greater than originally thought.
When you say that the aptosid kernel is plain vanila that means to me that you get your kernels directly from kernel.org. If that is not what you meant please correct me.
If I am over reacting, it wouldn't be the first time. |
|
|
| |
|
|
|
|
|
dibl
|
|
|
Post subject:
Posted: 10.09.2011, 17:34
|
|
Joined: 2010-09-12
Posts: 302
Location: Dayton, Ohio, USA
Status: Offline
|
|
| An unfortunate side effect of the kernel.org shutdown -- that is the source for some needed firmware, as linked in the aptosid manual, for example Atheros wifi firmware. Perhaps it is possible to work around with ndiswrapper, but that is not a desirable method. |
|
|
| |
|
|
|
|
|
CaesarTjalbo
|
|
|
Post subject:
Posted: 10.09.2011, 23:55
|
|
Joined: 2010-09-13
Posts: 95
Location: Enschede
Status: Offline
|
|
|
jheaton5 wrote:
When you say that the aptosid kernel is plain vanila that means to me that you get your kernels directly from kernel.org.
That would seem so. There is no way to guarantee the integrity of the software you receive or the hardware you run it on. |
|
|
| |
|
|
|
|
|
|
