Pourquoi ne pas avoir un office de brevet qui fonctionne sur un budget accordé par l'Etat et, donc, qui ne touche pas d'argent sur les dépoôs de brevets ?
Avec ce système plus d'incitation malsaine à accepter tout et n'importe quoi afin de faire rentrer du fric.
>>> se retire d'une des briques essentielles du noyau
Une brique essentielle qui n'avait pas été maintenu depuis des années et des années.
L'article LWN cite le fait que le copyright du fichier drivers/char/tty_io.c est toujours "Copyright (C) 1991, 1992, Linus Torvalds" donc ça montre bien que c'est un truc que personne ne touche.
Alan avait commencé un travail de nettoyage et réécriture mais visiblement il laisse tomber. C'est pas la fin du monde.
L'explication vulgarisée tirée de l'article LWN : "The problem with kdesu appears to be a KDE bug; the application would read too much data, then wonder why the next read didn't have what it wanted. This code worked with the older TTY code, but broke with 2.6.31. There is probably no way to fix it which doesn't saddle the kernel with maintaining weird legacy bug-compatibility code - something the TTY layer does not need more of. "
Et cette réécriture elle est dispo dans un version stable de FreeBSD ou bien elle fera juste partie de la future release 8.0 ?
Parce que si c'est ça et bien c'est à ce moment là et à ce moment là seulement qu'on pourra juger de la compatibilité de cette nouvelle implémentation avec toutes les applications en user space qui existent.
C'est bien ça le souci. Tout le monde est d'accord pour dire que tty c'est pourri, c'est horrible, c'est effroyable....mais si on change tout alors on risque de casser toutes les applis qui utilisent tty.
>>> en résumé, il faut écrire au Vatican, demander son apostasie, et tu reçois un papier qui te dit que tu as été rayé des registres de l'église.
Écrire au Vatican ? Moi j'ai juste écrit à mon diocèse de baptême et afin de leur demander de me rayer des registres et ils m'ont confirmé quelques semaines plus tard que c'était fait.
C'est très simple à faire.
>>> AES/SHA te certifie que la communauté de la cryptanalyse pense que cette fonction est robuste, rapide et implémentable sur tout type de plateforme. C'est un "survival of the fittest"
A noter toutefois que la compétition organisée par le NIST, même si elle est la plus célèbre, n'est pas la seule.
La commission européenne a organisé le projet NESSIE entre 2000 et 2003 : http://fr.wikipedia.org/wiki/Projet_NESSIE
Là aussi il y a eu évaluation par des cryptographes du monde entier et là aussi il y a eu une sélection finale d'algorithmes.
Par exemple le gagnant des fonctions de hachages, outre les SHA-x, a été l'algorithme Whirlpool conçu entre autre par Vincent Rijmen, l'un des auteurs d'AES : http://fr.wikipedia.org/wiki/Whirlpool_%28algorithme%29
Merci en tout cas pour tes posts informatifs.
C'est vrai que c'est difficile de se faire une opinion objective sur l'opération à Gaza et sur la situation en général quand on n'a jamais mis les pieds là-bas, quand on n'a jamais parlé aux gens sur place, etc
D'un autre côté le simple fait de vivre là-bas de donne pas non plus la science infuse sur ce conflit très compliqué, je pense que tu en est parfaitement conscient.
Nous qui vivons loin du conflit et qui sommes à la merci des infos des grands médias, que pouvons-nous faire pour essayer de démêler le vrai du faux et se faire une idée de ce qui s'est passé à Gaza ? Comment, toi qui habites Beer-Sheva, peux-tu compléter tes connaissances locales par des données les plus objectives possibles ?
A mon avis un bon début c'est de lire le rapport sur l'opération de Gaza qui a été écrit par une organisation non-gouvernementale "neutre" et n'ayant aucune partialité pour l'un ou l'autre protagoniste du conflit.
Il fait 127 pages mais c'est important de le lire si on ne veut pas parler dans le vide et être accusé de seulement écouter les "journalistes" à 3000 km de distance.
>>> Moi au contraire je trouves assez revelateur qu'un gars avec de fortes connaissances en securite utilise Vista et Win7 comme son desktop principal.
J'ai reçu un mail de Spender qui a vu qu'il y avait des commentaires dans la dépêche à propos de son utilisation de Windows :
I saw some questions on there in the comments about why I would use
Windows if I'm so interested in security. Though my choice to use the
OS as mentioned was for usability/productivity purposes, I do a number
of things on Windows to increase security compared to the default
install:
I browse/IM etc within a virtual machine. DEP (the windows equivalent
of PaX's PAGEEXEC) is forced on for every application (by default it's
not enabled on things like Firefox or Office). I also enable a new,
little-known feature called SEHOP. I've also written a utility that
displays what loaded DLLs have ASLR disabled and can modify their
binaries so that ASLR is turned on.
The machine is NATted behind a Linux machine running iptables.
I don't have any need for Anti-Virus software, and with my
reverse-engineering background can inspect binaries I believe are
suspicious. I then can then take a VM snapshot, run the binary, and
revert it afterwards.
Actual grsecurity development of course is done on either a real Linux
box or a Linux VM, and I always have a number of SSH sessions open to
Linux machines every day.
You can post this response if you feel it's useful :)
Ouais enfin il parle surtout de l'install des softs et du nombre de jeux dispos...alors bon ton lien avec une supposée super sécurité de Windows je ne le vois pas trop.
> #####
> You
> #####
>
> 01) Wich OS do you use daily on your laptop/desktop and why did you
> choose this OS ?
I know this will probably upset some of your readers, but I actually
am running Windows 7 RC right now. Prior to that I had been running
Windows Vista. I haven't used Linux as a primary desktop since college
or so. Now that I have a job and my free time is limited, I can't be
wasting days trying to get some driver to work, or trying to recover a
totally broken system because I haven't updated in a while and now want
to upgrade pidgin. If I want to update a specific application on the
machine, I only want to update that specific application -- I don't want
140 other dependencies forced on me. So for reasons of maintaining
sanity (and being able to play games, not just the ones supported by
Wine/Cedega), I use Windows. Linux stays inside VMs on my main
machine, though I do have some machines here that run Linux on the raw
hardware for grsecurity testing purposes.
> 02) Generally what do you think about the free (as in freedom) sofware
> movement ? Did you care about the philosophy behind free softwares
> (like RMS) or did you care only about the technical merits of this
> development model (like Linus) ?
Well, without the free software movement, a lot of the software I use
wouldn't exist (nor would the software I create) so I'm thankful for
that. Initially I cared that it was free (as in beer) and having source
code available was a great learning resource.
>
> 03) I there really a market for selling vulnerabilities ? Did you ever
> sell a vulnerability to a legitimate purchasers ? Did you ever
> consider selling a vulnerability to a blackhat ?
Yes, there really is a market: iDefense, ZDI, Immunity, etc buy
exploits. I have sold vulnerabilities/exploits before to a legitimate
purchaser. I would never sell a vulnerability though to any
illegitimate purchaser or sell any vulnerabilities in any way related to
grsecurity, as that would completely defeat the point of the project
(and be highly unethical).
> 04) There is a lot of funny comments in the source code of your
> exploit (and ascii art also). Is it fun to write exploit ? Is there a
> feeling of ecstactic joy when you find a hole in the kernel ?
Cheddar Bay was lots of fun to write :) From ascii art to system beeps
to an interactive text adventure, to French existentialist literature
(at the very end), the exploit being 31337 bytes, the tarball being
12345 bytes -- it was very true as mentioned in the exploit that most of
the time was spent on the audio/visual experience of it. The actual
technical aspect of the exploit was quite easy (much to the
embarrassment of those involved, I suppose, that someone in an hour of
their free time can tear down all the security protections that have
been built up). I may have a strange sense of humor, but I found it to
be hilarious, and I think some others saw the absurdity/humor in it as
well. Finding good holes in the kernel is exciting, but there are lots
of holes in general, so the overall feeling is one of depression :)
> 05) I've seen this post by Ingo Molnar in LWN :
> http://lwn.net/Articles/342163/ Do you think security experts and
> exploits creator like you have a different mindset compared to other
> kernel developpers ? Is there downsides (psychological or others) to
> be a exploit creator ?
Well, I'm a developer as well, but I also understand that particularly
in the security field, you have to think offensively. That sometimes
means actually doing the work to research vulnerabilities and exploiting
them. It means collaborating with other people who do similar research.
It means never resting on your laurels, always second-guessing your
code, and actively trying to break it. We don't have the mindset of
"well we just wrote <security feature> and think it works, time to
congratulate ourselves." Someone who focuses entirely on kernel
development just can't compete with the talent of people who focus
entirely on security, when it comes to matters of security. Exploit
writing perhaps involves more creative thinking than would be involved
in normal development, but no, we don't have any more psychological
problems than normal developers ;)
> #####
> Grsecurity
> #####
>
> 06) Do you think your recent exploit would have been possible with a
> grsecurity patched kernel ?
Well, for starters, we haven't released a 2.6.30 patch yet, and as that
kernel (or 2.6.30.1) was required to have the vulnerability, then from
the get-go no grsecurity-patched kernels were vulnerable. Now if we
were to imagine a scenario where the bug existed for the 2.6.29.6
kernel, for which there does exist a grsecurity patch, there are a
number of things that would stand in its way:
PaX's UDEREF - This will prevent the vulnerability from being
exploitable from the get-go. Not only does it protect against NULL
pointer dereferences, but against any invalid userland access in general
by the kernel.
PaX's KERNEXEC - This is an effort at removing the ability for arbitrary
code execution in the kernel, just as is done in userland. On top of
this, it makes sections of the kernel marked to be read-only actually
read-only. On a normal kernel, "read-only data" is actually writable.
The particular file_operation function pointer I modified in my exploit
existed in this region of memory that should have been read-only.
KERNEXEC would have prevented its modification. KERNEXEC also comes
into play to prevent ring0 execution in userland, which my exploit also
used. I wrote up a demo exploit for another vulnerability yesterday
that uses the capability of making the kernel execute code in userland
-- no NULL ptr dereference involved. KERNEXEC would step in and prevent
that.
grsec's HIDESYM - This (preferably when used with the RBAC system or
with /boot and /usr/src unreadable by non-root users) aims to keep an
attacker from knowing where specific things he/she wants to attack are
located. Much of what made Cheddar Bay so small and simple was due to
the fact that vendor kernels ship with CONFIG_KALLSYMS_ALL enabled,
which gives an attacker a symbol -> address mapping for virtually
anything he/she is interested in. Without reliable information on what
to attack (so as not to panic the kernel and lose the ability to exploit
it), an attacker would likely need an additional information leaking
vulnerability (something I came up with, which is now PAX_USERCOPY,
could help here even).
> 07) I've seen in the grsecurity website a fierce critic of LSM :
> http://grsecurity.net/lsm.php I've also seen that LSM was modified
> recently in order to add pathname based security modules (TOMOYO). Do
> you think it's possible to have some additional LSM modifications in
> order to merge in mainline some part of grsecurity ?
We're not interested in having parts of grsecurity in the mainline
kernel. Many of the features of grsecurity provide an additive effect
that wouldn't exist if only one of its features happened to be
implemented. For instance, the way UDEREF and KERNEXEC work together to
prevent both code execution and data access in userland by the kernel.
Or the anti-bruteforcing and anti-information leaking added to
grsecurity in support of PaX's ASLR. You don't get the security of
defense in depth unless you actually have the 'depth'.
> 08) Generally, considering the rapid pace of Linux development, is it
> possible to maintain an external patch like grsecurity ?
If you're not aware of the 'test' patches we are continually working on,
we do generally keep up with each new stable version of the Linux
kernels. Due to some constraints on free time lately for both myself
and the PaX team we don't have the patch out yet for 2.6.30, but this is
an exception rather than the rule. The development pace does make
things difficult, especially for a two-man team. It's also no good
security-wise to be introducing 80MB of changes into a supposedly stable
kernel every three months. So it is unfortunate that much of our time
goes into this constant porting work that could better be spent on
actually implementing new security technologies.
> 09) After the grsecurity sponsor alert at the end of last year there
> was some lkml mails in january asking for the incorporation of
> grsecurity in linux. The answer from linus
> (http://thread.gmane.org/gmane.linux.kernel/774825/focus=7748(...) or
> from Robert Hancock
> (http://thread.gmane.org/gmane.linux.kernel/774825/focus=7751(...) was
> that the global patch must be splitted in small parts that make sense.
> What do you think about this option ? Is there a real effort currently
> in order to merge grsecurity in mainline ?
You'll notice that in any mention of grsecurity being merged mainline,
there is a distinct lack of something: our involvement in the
discussion. Put simply, people asking to have grsecurity merged into
mainline don't speak for us, and it wouldn't save us any time (we'd end
up wasting time arguing with non-security experts on how something should
be done within their kernel, when we'd rather just get things done.)
> 10) Some says that you don't want to incorporate grsecurity in
> mainline because it means you will lose your livelihood. Is it true ?
> Do you earn a lot of money with grsecurity as an external patch ?
It's not true. If grsecurity were my main source of income, I would be
homeless. I wish it were the case that I made a lot of money from it
(we always welcome new sponsors), but it's simply not true. I earned
just enough last year from grsecurity to pay for hardware for testing
and colo/network fees (which were lifted this year thanks to our
provider), so grsecurity is not something I profit from.
> 11) I've seen the impressive graph of grsecurity influence
> http://grsecurity.net/~spender/grsecurity_pax-influence.png Do you
> ever consider to use patent with your software developpement in
> grsecurity ? What do you think about software patent in general ?
I can only speak for myself, but I have no interest or plans on
patenting anything, and dislike software patents in general.
> #####
> OpenBSD
> ####"
>
> 12) Concerning security what do you think about the general code
> quality of the OpenBSD kernel compared to the general code quality of
> the Linux kernel ? Is the security reputation of OpenBSD really
> deserved ?
First off, as a general statement about OpenBSD (since there are a
couple questions here about them) I don't really find them to be
relevant anymore (if they ever were). Back years ago when I first
started working on grsecurity, OpenBSD was of the mentality that source
code review alone could save them -- as they discovered, that strategy
doesn't work out too well. Since then they've been adding on defensive
measures, but several years behind others in the industry. For
instance, it wasn't too long ago that they finally supported PIE
binaries. The default install security track record is also more of a
gimmick than anything, since nearly nothing is enabled. If you have
nearly nothing enabled, then there's nearly nothing to protect -- not
much of a statement of security.
Their code quality is probably better than Linux (I don't waste my time
auditing it), but their kernel is also more primitive in a lot of ways
than Linux -- so in some respects it's like comparing apples and
oranges. The speed of development in Linux is also much faster. So
I'm not really praising the Linux code quality here, just making the
point that I don't feel it matters much if your code quality is amazing
if hardly anyone uses your OS. The same could be said about Linux
compared to Windows though, so it should just be said that developers
will work on whatever they happen to be interested in, and some OSes
are more used than others.
Finally, it should be mentioned that Linux at least is developed by in
large part by people who started the whole thing and more or less
understand its code base. OpenBSD on the other hand inherited a code
base they still don't quite understand today.
> 13) I heard that, each time a new security problem, OpenBSD
> developpers grep the entire code base in order to fix all occurence of
> this problem. Why Linux developpers don't do the same thing ?
First off, most bug classes can't be grepped for. I'm not really sure
that Linux developers don't try to find other bugs of the same type
after an important one's discovered -- I've seen some commits lately in
response to the Cheddar Bay exploit that suggests some Linux developers
are actually making an effort to find other cases of a particular bug
class. However, it should also be noted that at least OpenBSD accepts
the notion of security vulnerabilities. The official Linux policy is
that no bug is more important than another (which is both a lie and
disappointing to see in such a widely-used OS).
>
> 14) What do you think about the strlcpy and strlcat functions used in
> OpenBSD ? Do you think they should be added in glibc and used in Linux
> ?
Anyone who wants to replace exploitable overflows with exploitable
string truncation is free to add their own copy of strlcpy and strlcat
to their source code. I don't see any reason for it to be added to
glibc.
> 15) Is there lessons from OpenBSD that should be adopted by Linux
> developpers or are the two OS too different to adopt the same method ?
Someone has suggested I say that the lesson is that "code written by
jerks will be used only by jerks" but I am more kind than that ;) It's
not a useful question to hypothesize an answer to as we've learned more
than once that Linux development is quite set in its ways.
>
> #####
> Linux
> #####
>
> 16) You said that that kernel security bugs are silently fixed by the
> -stable mainteners. Could you explain why it's important to dedicate
> resources in order to correctly classify bugs ? Is it really possible
> to correctly classify security bugs ? If users apply all the fixs
> anyway why try to classify bugs ?
It's important because when bugs aren't correctly classified, then you
cannot accurately determine risk. It's not possible to perfectly
classify security bugs (there will always be someone with some unique
trick) but it is certainly possible to do a lot better than calling
everything a DoS unless there's a public exploit for it. Linux vendors
take in hundreds of millions of dollars in revenue, so there's no excuse
for them not to spend resources to take the handling of security
problems seriously. In the ideal world, everyone would apply all the
fixes, but back in the real world that doesn't happen. Why should you
have to apply a fix that doesn't apply to you? There are simply too
many bugs reported in the Linux kernel for people to be updating every
time one is announced. They're surely more likely to upgrade though if
there're affected by a remote root exploit that disables SELinux than if
it's yet another DoS in some driver code they don't even have compiled
into their kernel. So it's important that people be given adequate
information so that they can accurately evaluate risk for their
particular deployments.
> 17) Do you think the Linux kernel need a security officer ? If yes and
> if you were this security officer, with real power, what would be your
> first decisions ?
I'm not sure any single security officer could be effective within the
Linux kernel community. Performance is king, and many of the developers
simply don't 'get' security in the way people within the industry do. I
imagine anyone with such a job would be incredibly frustrated.
If I had real power and actually had a solution to the problems that the
current development model causes, while keeping fans of the current
development model happy, I would focus on that. Unfortunately I'm not
sure any such solution exists.
>
> 18) In the past you criticized Linus Torvalds about the security of
> the kernel. What do you think about his decisions concerning security
> ? About his technical habilities in this specific domain ? About his
> general leadership of the project ?
He at times can understand security better than some of the other
developers, but security isn't one of his main goals. I'm not sure
either that he fully understand his user-base, particularly corporate
users, but that probably all has to do with the commercialization of
Linux -- it's the job of the vendors to worry about things like that,
and Linus to just worry about driving the creation of the kernel in ways
he thinks is best. His ideas regarding security that have formed the
official policy of kernel developers to omit security-relevant
information in changelogs and treat all bugs the same are destructive.
It's not just me that complains about this, but even the vendors
themselves admit that trying to hide security bugs makes their job of
backporting security fixes much more difficult.
> 19) I order to have a really secure OS do you think we must use
> another paradigm (microkernel, managed OS, formally verified OS, etc)
> or is the current architecture of the Linux kernel compatible with
> real security ?
The "weak link", the thing being trusted by security systems, is the
kernel itself. So the kernel needs to be protected from itself, that
much is sure. We've spent a lot of time working in this area
(especially the PaX Team) and there are more great things planned for
the future. So as to whether this self-protection can be done within
the current architecture or not, is something you'll have to wait to see
for yourself ;)
Thanks for the questions, and hope I didn't cause too many flames :)
Ben ce serait bizarre de poster un article en anglais sur linuxfr non ?
J'ai proposé ça sur la mailing list modéro mais c'est vrai que je ne savait absolument pas comment faire pour éviter d'avoir une grosse news en anglais en plein milieu du site.
Si tu a une solution je suis ouvert. Je peux envoyer l'interview originale en anglais à qui me le demande (envoyer un mail sur mon adresse dlfp).
[^] # Re: !!!
Posté par patrick_g (site web personnel) . En réponse à la dépêche Microsoft se voit attribuer un brevet sur les traitements de texte utilisant XML. Évalué à 5.
Avec ce système plus d'incitation malsaine à accepter tout et n'importe quoi afin de faire rentrer du fric.
# Demo
Posté par patrick_g (site web personnel) . En réponse au journal Roundcube, simple mais super efficace !. Évalué à 6.
Tellement l'eau à la bouche qu'il n'est plus possible de se connecter à la démo tellement il y a de monde :-(
[^] # Re: amen
Posté par patrick_g (site web personnel) . En réponse au journal Alan Cox jette l'éponge. Évalué à 4.
[^] # Re: amen
Posté par patrick_g (site web personnel) . En réponse au journal Alan Cox jette l'éponge. Évalué à 5.
/mode pédant off
[^] # Re: un titre à scandale
Posté par patrick_g (site web personnel) . En réponse au journal Alan Cox jette l'éponge. Évalué à 9.
Une brique essentielle qui n'avait pas été maintenu depuis des années et des années.
L'article LWN cite le fait que le copyright du fichier drivers/char/tty_io.c est toujours "Copyright (C) 1991, 1992, Linus Torvalds" donc ça montre bien que c'est un truc que personne ne touche.
Alan avait commencé un travail de nettoyage et réécriture mais visiblement il laisse tomber. C'est pas la fin du monde.
[^] # Re: kdesu ?
Posté par patrick_g (site web personnel) . En réponse au journal Alan Cox jette l'éponge. Évalué à 4.
L'explication vulgarisée tirée de l'article LWN : "The problem with kdesu appears to be a KDE bug; the application would read too much data, then wonder why the next read didn't have what it wanted. This code worked with the older TTY code, but broke with 2.6.31. There is probably no way to fix it which doesn't saddle the kernel with maintaining weird legacy bug-compatibility code - something the TTY layer does not need more of. "
[^] # Re: Pendant ce temps dans FreeBSD ...
Posté par patrick_g (site web personnel) . En réponse au journal Alan Cox jette l'éponge. Évalué à 10.
Parce que si c'est ça et bien c'est à ce moment là et à ce moment là seulement qu'on pourra juger de la compatibilité de cette nouvelle implémentation avec toutes les applications en user space qui existent.
C'est bien ça le souci. Tout le monde est d'accord pour dire que tty c'est pourri, c'est horrible, c'est effroyable....mais si on change tout alors on risque de casser toutes les applis qui utilisent tty.
# Erreur
Posté par patrick_g (site web personnel) . En réponse au journal Alan Cox jette l'éponge. Évalué à 10.
Non il arrête juste de bosser sur l'immonde plat de spaghettis qu'est tty...mais évidemment il n'arrête pas de bosser sur le reste du noyau.
[^] # Re: Généralisations…
Posté par patrick_g (site web personnel) . En réponse au journal Système d'exploitation et religion. Évalué à 3.
Écrire au Vatican ? Moi j'ai juste écrit à mon diocèse de baptême et afin de leur demander de me rayer des registres et ils m'ont confirmé quelques semaines plus tard que c'était fait.
C'est très simple à faire.
[^] # Re: Et sinon ?
Posté par patrick_g (site web personnel) . En réponse au journal Petit test de FreeBSD 8.0. Évalué à 1.
[^] # Re: dommage...
Posté par patrick_g (site web personnel) . En réponse au journal Une CB Visa en partenariat avec la FSF. Évalué à 2.
[^] # Re: MD6
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 6.
A noter toutefois que la compétition organisée par le NIST, même si elle est la plus célèbre, n'est pas la seule.
La commission européenne a organisé le projet NESSIE entre 2000 et 2003 : http://fr.wikipedia.org/wiki/Projet_NESSIE
Là aussi il y a eu évaluation par des cryptographes du monde entier et là aussi il y a eu une sélection finale d'algorithmes.
Par exemple le gagnant des fonctions de hachages, outre les SHA-x, a été l'algorithme Whirlpool conçu entre autre par Vincent Rijmen, l'un des auteurs d'AES : http://fr.wikipedia.org/wiki/Whirlpool_%28algorithme%29
[^] # Re: The SHA-3 Zoo
Posté par patrick_g (site web personnel) . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 3.
[^] # Continuons le off topic
Posté par patrick_g (site web personnel) . En réponse à la dépêche La Ligue ODEBI lance un projet "d'armée numérique". Évalué à 8.
C'est vrai que c'est difficile de se faire une opinion objective sur l'opération à Gaza et sur la situation en général quand on n'a jamais mis les pieds là-bas, quand on n'a jamais parlé aux gens sur place, etc
D'un autre côté le simple fait de vivre là-bas de donne pas non plus la science infuse sur ce conflit très compliqué, je pense que tu en est parfaitement conscient.
Nous qui vivons loin du conflit et qui sommes à la merci des infos des grands médias, que pouvons-nous faire pour essayer de démêler le vrai du faux et se faire une idée de ce qui s'est passé à Gaza ? Comment, toi qui habites Beer-Sheva, peux-tu compléter tes connaissances locales par des données les plus objectives possibles ?
A mon avis un bon début c'est de lire le rapport sur l'opération de Gaza qui a été écrit par une organisation non-gouvernementale "neutre" et n'ayant aucune partialité pour l'un ou l'autre protagoniste du conflit.
Le rapport d'Amnesty International : http://www.amnesty.org/en/library/info/MDE15/015/2009/en
Il fait 127 pages mais c'est important de le lire si on ne veut pas parler dans le vide et être accusé de seulement écouter les "journalistes" à 3000 km de distance.
[^] # Re: Anti-Windowsiens primaire
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 7.
[^] # Re: Original version for the non French-speaking readers
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 2.
[^] # Re: Original version for the non French-speaking readers
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 2.
Bon je traduis et je corrige la news.
[^] # Re: Très drôle :)
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 10.
J'ai reçu un mail de Spender qui a vu qu'il y avait des commentaires dans la dépêche à propos de son utilisation de Windows :
I saw some questions on there in the comments about why I would use
Windows if I'm so interested in security. Though my choice to use the
OS as mentioned was for usability/productivity purposes, I do a number
of things on Windows to increase security compared to the default
install:
I browse/IM etc within a virtual machine. DEP (the windows equivalent
of PaX's PAGEEXEC) is forced on for every application (by default it's
not enabled on things like Firefox or Office). I also enable a new,
little-known feature called SEHOP. I've also written a utility that
displays what loaded DLLs have ASLR disabled and can modify their
binaries so that ASLR is turned on.
The machine is NATted behind a Linux machine running iptables.
I don't have any need for Anti-Virus software, and with my
reverse-engineering background can inspect binaries I believe are
suspicious. I then can then take a VM snapshot, run the binary, and
revert it afterwards.
Actual grsecurity development of course is done on either a real Linux
box or a Linux VM, and I always have a number of SSH sessions open to
Linux machines every day.
You can post this response if you feel it's useful :)
-Brad
[^] # Re: Très drôle :)
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 9.
# Original version for the non French-speaking readers
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 10.
> You
> #####
>
> 01) Wich OS do you use daily on your laptop/desktop and why did you
> choose this OS ?
I know this will probably upset some of your readers, but I actually
am running Windows 7 RC right now. Prior to that I had been running
Windows Vista. I haven't used Linux as a primary desktop since college
or so. Now that I have a job and my free time is limited, I can't be
wasting days trying to get some driver to work, or trying to recover a
totally broken system because I haven't updated in a while and now want
to upgrade pidgin. If I want to update a specific application on the
machine, I only want to update that specific application -- I don't want
140 other dependencies forced on me. So for reasons of maintaining
sanity (and being able to play games, not just the ones supported by
Wine/Cedega), I use Windows. Linux stays inside VMs on my main
machine, though I do have some machines here that run Linux on the raw
hardware for grsecurity testing purposes.
> 02) Generally what do you think about the free (as in freedom) sofware
> movement ? Did you care about the philosophy behind free softwares
> (like RMS) or did you care only about the technical merits of this
> development model (like Linus) ?
Well, without the free software movement, a lot of the software I use
wouldn't exist (nor would the software I create) so I'm thankful for
that. Initially I cared that it was free (as in beer) and having source
code available was a great learning resource.
>
> 03) I there really a market for selling vulnerabilities ? Did you ever
> sell a vulnerability to a legitimate purchasers ? Did you ever
> consider selling a vulnerability to a blackhat ?
Yes, there really is a market: iDefense, ZDI, Immunity, etc buy
exploits. I have sold vulnerabilities/exploits before to a legitimate
purchaser. I would never sell a vulnerability though to any
illegitimate purchaser or sell any vulnerabilities in any way related to
grsecurity, as that would completely defeat the point of the project
(and be highly unethical).
> 04) There is a lot of funny comments in the source code of your
> exploit (and ascii art also). Is it fun to write exploit ? Is there a
> feeling of ecstactic joy when you find a hole in the kernel ?
Cheddar Bay was lots of fun to write :) From ascii art to system beeps
to an interactive text adventure, to French existentialist literature
(at the very end), the exploit being 31337 bytes, the tarball being
12345 bytes -- it was very true as mentioned in the exploit that most of
the time was spent on the audio/visual experience of it. The actual
technical aspect of the exploit was quite easy (much to the
embarrassment of those involved, I suppose, that someone in an hour of
their free time can tear down all the security protections that have
been built up). I may have a strange sense of humor, but I found it to
be hilarious, and I think some others saw the absurdity/humor in it as
well. Finding good holes in the kernel is exciting, but there are lots
of holes in general, so the overall feeling is one of depression :)
> 05) I've seen this post by Ingo Molnar in LWN :
> http://lwn.net/Articles/342163/ Do you think security experts and
> exploits creator like you have a different mindset compared to other
> kernel developpers ? Is there downsides (psychological or others) to
> be a exploit creator ?
Well, I'm a developer as well, but I also understand that particularly
in the security field, you have to think offensively. That sometimes
means actually doing the work to research vulnerabilities and exploiting
them. It means collaborating with other people who do similar research.
It means never resting on your laurels, always second-guessing your
code, and actively trying to break it. We don't have the mindset of
"well we just wrote <security feature> and think it works, time to
congratulate ourselves." Someone who focuses entirely on kernel
development just can't compete with the talent of people who focus
entirely on security, when it comes to matters of security. Exploit
writing perhaps involves more creative thinking than would be involved
in normal development, but no, we don't have any more psychological
problems than normal developers ;)
> #####
> Grsecurity
> #####
>
> 06) Do you think your recent exploit would have been possible with a
> grsecurity patched kernel ?
Well, for starters, we haven't released a 2.6.30 patch yet, and as that
kernel (or 2.6.30.1) was required to have the vulnerability, then from
the get-go no grsecurity-patched kernels were vulnerable. Now if we
were to imagine a scenario where the bug existed for the 2.6.29.6
kernel, for which there does exist a grsecurity patch, there are a
number of things that would stand in its way:
PaX's UDEREF - This will prevent the vulnerability from being
exploitable from the get-go. Not only does it protect against NULL
pointer dereferences, but against any invalid userland access in general
by the kernel.
PaX's KERNEXEC - This is an effort at removing the ability for arbitrary
code execution in the kernel, just as is done in userland. On top of
this, it makes sections of the kernel marked to be read-only actually
read-only. On a normal kernel, "read-only data" is actually writable.
The particular file_operation function pointer I modified in my exploit
existed in this region of memory that should have been read-only.
KERNEXEC would have prevented its modification. KERNEXEC also comes
into play to prevent ring0 execution in userland, which my exploit also
used. I wrote up a demo exploit for another vulnerability yesterday
that uses the capability of making the kernel execute code in userland
-- no NULL ptr dereference involved. KERNEXEC would step in and prevent
that.
grsec's HIDESYM - This (preferably when used with the RBAC system or
with /boot and /usr/src unreadable by non-root users) aims to keep an
attacker from knowing where specific things he/she wants to attack are
located. Much of what made Cheddar Bay so small and simple was due to
the fact that vendor kernels ship with CONFIG_KALLSYMS_ALL enabled,
which gives an attacker a symbol -> address mapping for virtually
anything he/she is interested in. Without reliable information on what
to attack (so as not to panic the kernel and lose the ability to exploit
it), an attacker would likely need an additional information leaking
vulnerability (something I came up with, which is now PAX_USERCOPY,
could help here even).
> 07) I've seen in the grsecurity website a fierce critic of LSM :
> http://grsecurity.net/lsm.php I've also seen that LSM was modified
> recently in order to add pathname based security modules (TOMOYO). Do
> you think it's possible to have some additional LSM modifications in
> order to merge in mainline some part of grsecurity ?
We're not interested in having parts of grsecurity in the mainline
kernel. Many of the features of grsecurity provide an additive effect
that wouldn't exist if only one of its features happened to be
implemented. For instance, the way UDEREF and KERNEXEC work together to
prevent both code execution and data access in userland by the kernel.
Or the anti-bruteforcing and anti-information leaking added to
grsecurity in support of PaX's ASLR. You don't get the security of
defense in depth unless you actually have the 'depth'.
> 08) Generally, considering the rapid pace of Linux development, is it
> possible to maintain an external patch like grsecurity ?
If you're not aware of the 'test' patches we are continually working on,
we do generally keep up with each new stable version of the Linux
kernels. Due to some constraints on free time lately for both myself
and the PaX team we don't have the patch out yet for 2.6.30, but this is
an exception rather than the rule. The development pace does make
things difficult, especially for a two-man team. It's also no good
security-wise to be introducing 80MB of changes into a supposedly stable
kernel every three months. So it is unfortunate that much of our time
goes into this constant porting work that could better be spent on
actually implementing new security technologies.
> 09) After the grsecurity sponsor alert at the end of last year there
> was some lkml mails in january asking for the incorporation of
> grsecurity in linux. The answer from linus
> (http://thread.gmane.org/gmane.linux.kernel/774825/focus=7748(...) or
> from Robert Hancock
> (http://thread.gmane.org/gmane.linux.kernel/774825/focus=7751(...) was
> that the global patch must be splitted in small parts that make sense.
> What do you think about this option ? Is there a real effort currently
> in order to merge grsecurity in mainline ?
You'll notice that in any mention of grsecurity being merged mainline,
there is a distinct lack of something: our involvement in the
discussion. Put simply, people asking to have grsecurity merged into
mainline don't speak for us, and it wouldn't save us any time (we'd end
up wasting time arguing with non-security experts on how something should
be done within their kernel, when we'd rather just get things done.)
> 10) Some says that you don't want to incorporate grsecurity in
> mainline because it means you will lose your livelihood. Is it true ?
> Do you earn a lot of money with grsecurity as an external patch ?
It's not true. If grsecurity were my main source of income, I would be
homeless. I wish it were the case that I made a lot of money from it
(we always welcome new sponsors), but it's simply not true. I earned
just enough last year from grsecurity to pay for hardware for testing
and colo/network fees (which were lifted this year thanks to our
provider), so grsecurity is not something I profit from.
> 11) I've seen the impressive graph of grsecurity influence
> http://grsecurity.net/~spender/grsecurity_pax-influence.png Do you
> ever consider to use patent with your software developpement in
> grsecurity ? What do you think about software patent in general ?
I can only speak for myself, but I have no interest or plans on
patenting anything, and dislike software patents in general.
> #####
> OpenBSD
> ####"
>
> 12) Concerning security what do you think about the general code
> quality of the OpenBSD kernel compared to the general code quality of
> the Linux kernel ? Is the security reputation of OpenBSD really
> deserved ?
First off, as a general statement about OpenBSD (since there are a
couple questions here about them) I don't really find them to be
relevant anymore (if they ever were). Back years ago when I first
started working on grsecurity, OpenBSD was of the mentality that source
code review alone could save them -- as they discovered, that strategy
doesn't work out too well. Since then they've been adding on defensive
measures, but several years behind others in the industry. For
instance, it wasn't too long ago that they finally supported PIE
binaries. The default install security track record is also more of a
gimmick than anything, since nearly nothing is enabled. If you have
nearly nothing enabled, then there's nearly nothing to protect -- not
much of a statement of security.
Their code quality is probably better than Linux (I don't waste my time
auditing it), but their kernel is also more primitive in a lot of ways
than Linux -- so in some respects it's like comparing apples and
oranges. The speed of development in Linux is also much faster. So
I'm not really praising the Linux code quality here, just making the
point that I don't feel it matters much if your code quality is amazing
if hardly anyone uses your OS. The same could be said about Linux
compared to Windows though, so it should just be said that developers
will work on whatever they happen to be interested in, and some OSes
are more used than others.
Finally, it should be mentioned that Linux at least is developed by in
large part by people who started the whole thing and more or less
understand its code base. OpenBSD on the other hand inherited a code
base they still don't quite understand today.
> 13) I heard that, each time a new security problem, OpenBSD
> developpers grep the entire code base in order to fix all occurence of
> this problem. Why Linux developpers don't do the same thing ?
First off, most bug classes can't be grepped for. I'm not really sure
that Linux developers don't try to find other bugs of the same type
after an important one's discovered -- I've seen some commits lately in
response to the Cheddar Bay exploit that suggests some Linux developers
are actually making an effort to find other cases of a particular bug
class. However, it should also be noted that at least OpenBSD accepts
the notion of security vulnerabilities. The official Linux policy is
that no bug is more important than another (which is both a lie and
disappointing to see in such a widely-used OS).
>
> 14) What do you think about the strlcpy and strlcat functions used in
> OpenBSD ? Do you think they should be added in glibc and used in Linux
> ?
Anyone who wants to replace exploitable overflows with exploitable
string truncation is free to add their own copy of strlcpy and strlcat
to their source code. I don't see any reason for it to be added to
glibc.
> 15) Is there lessons from OpenBSD that should be adopted by Linux
> developpers or are the two OS too different to adopt the same method ?
Someone has suggested I say that the lesson is that "code written by
jerks will be used only by jerks" but I am more kind than that ;) It's
not a useful question to hypothesize an answer to as we've learned more
than once that Linux development is quite set in its ways.
>
> #####
> Linux
> #####
>
> 16) You said that that kernel security bugs are silently fixed by the
> -stable mainteners. Could you explain why it's important to dedicate
> resources in order to correctly classify bugs ? Is it really possible
> to correctly classify security bugs ? If users apply all the fixs
> anyway why try to classify bugs ?
It's important because when bugs aren't correctly classified, then you
cannot accurately determine risk. It's not possible to perfectly
classify security bugs (there will always be someone with some unique
trick) but it is certainly possible to do a lot better than calling
everything a DoS unless there's a public exploit for it. Linux vendors
take in hundreds of millions of dollars in revenue, so there's no excuse
for them not to spend resources to take the handling of security
problems seriously. In the ideal world, everyone would apply all the
fixes, but back in the real world that doesn't happen. Why should you
have to apply a fix that doesn't apply to you? There are simply too
many bugs reported in the Linux kernel for people to be updating every
time one is announced. They're surely more likely to upgrade though if
there're affected by a remote root exploit that disables SELinux than if
it's yet another DoS in some driver code they don't even have compiled
into their kernel. So it's important that people be given adequate
information so that they can accurately evaluate risk for their
particular deployments.
> 17) Do you think the Linux kernel need a security officer ? If yes and
> if you were this security officer, with real power, what would be your
> first decisions ?
I'm not sure any single security officer could be effective within the
Linux kernel community. Performance is king, and many of the developers
simply don't 'get' security in the way people within the industry do. I
imagine anyone with such a job would be incredibly frustrated.
If I had real power and actually had a solution to the problems that the
current development model causes, while keeping fans of the current
development model happy, I would focus on that. Unfortunately I'm not
sure any such solution exists.
>
> 18) In the past you criticized Linus Torvalds about the security of
> the kernel. What do you think about his decisions concerning security
> ? About his technical habilities in this specific domain ? About his
> general leadership of the project ?
He at times can understand security better than some of the other
developers, but security isn't one of his main goals. I'm not sure
either that he fully understand his user-base, particularly corporate
users, but that probably all has to do with the commercialization of
Linux -- it's the job of the vendors to worry about things like that,
and Linus to just worry about driving the creation of the kernel in ways
he thinks is best. His ideas regarding security that have formed the
official policy of kernel developers to omit security-relevant
information in changelogs and treat all bugs the same are destructive.
It's not just me that complains about this, but even the vendors
themselves admit that trying to hide security bugs makes their job of
backporting security fixes much more difficult.
> 19) I order to have a really secure OS do you think we must use
> another paradigm (microkernel, managed OS, formally verified OS, etc)
> or is the current architecture of the Linux kernel compatible with
> real security ?
The "weak link", the thing being trusted by security systems, is the
kernel itself. So the kernel needs to be protected from itself, that
much is sure. We've spent a lot of time working in this area
(especially the PaX Team) and there are more great things planned for
the future. So as to whether this self-protection can be done within
the current architecture or not, is something you'll have to wait to see
for yourself ;)
Thanks for the questions, and hope I didn't cause too many flames :)
-Brad
[^] # Re: C'est Patrick_g !
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 4.
[^] # Re: C'est Patrick_g !
Posté par patrick_g (site web personnel) . En réponse à la dépêche Une interview de Brad Spengler. Évalué à 6.
J'ai proposé ça sur la mailing list modéro mais c'est vrai que je ne savait absolument pas comment faire pour éviter d'avoir une grosse news en anglais en plein milieu du site.
Si tu a une solution je suis ouvert. Je peux envoyer l'interview originale en anglais à qui me le demande (envoyer un mail sur mon adresse dlfp).
[^] # Re: Moi aussi j'aimerais bien avoir un recul des mes activites comme ca.
Posté par patrick_g (site web personnel) . En réponse au journal Microsoft clôt une année noire sur un recul généralisé de ses activités. Évalué à 10.
Bénéfice annuel = 14, 57 milliards de dollars
Marge bénéficiaire : 25%
Je ne connais presque aucun industriel qui peut se permettre ce genre de marge ahurissante....c'est bien le résultat d'un monopole.
[^] # Re: en termes d'exclusion...
Posté par patrick_g (site web personnel) . En réponse au journal Linus à propos des contributions de Microsoft. Évalué à 2.
[^] # Re: utopie technologique
Posté par patrick_g (site web personnel) . En réponse au journal Un nouvel espoir pour la voiture électrique?. Évalué à 4.
C'est faux. Avec un surgénérateur tu produis ton combustible.