patrick_g a écrit 6397 commentaires

Ayé.

Purée je viens de m'apercevoir que j'ai oublié de traduire un bout de sa réponse à la question 17 :(
Bon je traduis et je corrige la news.

>>> 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 :)

-Brad

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 :)

-Brad

Je peux essayer de faire un commentaire dans cette dépêche en mettant l'interview en VO ?

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).

Chiffre d'affaire annuel = 58,44 milliards de dollars
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.

Cnepr dhr yrf rkgeézvfgrf qr gbhg cbvy ar fnirag cnf qépbqre yr EBG13 ?

>>> il s'agit là encore d'une énergie non renouvelable, dont nous savons pas produire la matière première

C'est faux. Avec un surgénérateur tu produis ton combustible.

ben y'a pas un système de liste blanche dans NoScript ?

>>> Je demande que aussi simplement, on puisse avoir aces au niveau -42

Tu va sur ta page perso linuxfr : http://linuxfr.org/~Riend
Tu cliques sur le lien "Modifier vos préférences" qui se trouve à gauche
Parmi les différents choix tu coche la case "Activer la barre d'outils du site".
Ensuite quand tu ira sur un journal ou une news tu verra en bas à gauche le lien te permettant de régler to seuil : http://farm4.static.flickr.com/3477/3746274091_bec2abb5ed_o.(...)

Ben c'est quand même un gros boulot de tout migrer non ? Donc quand on décide de sauter le pas il faut que ce soit vers une solution pérenne à long terme il me semble.

Ce qui m'étonne c'est que KDE utilisait SVN depuis quand même assez peu d'années. je me souviens encore d'une petite news que j'avais rédigé au moment de l'annonce de la fin de la migration vers SVN => https://linuxfr.org//2005/05/11/18915.html et c'était il y a à peine 4 ans.
Si ils se tapent une grosse migration de tout leur source et de tout leur historique tous les 4 ans c'est que la planification à long terme n'a pas été super efficace je pense.

Bon est-ce qu'on pourrait stopper ce débat terminologique un peu absurde ? Il est évident que la réponse à apporter à la question "qui est le premier africain dans l'espace ?" dépend de la signification que l'on souhaite mettre dans le mot africain.

- Est-ce que ça veut simplement dire être né sur le continent africain ? Si oui alors c'est Baudry.
- Est-ce que ça veut simplement dire dire être citoyen d'un pays localisé sur le continent africain ? Si oui alors c'est Shuttleworth.
- Est-ce que ça veut simplement dire être de peau noire ? Si oui alors c'est Bluford.
- Est-ce que ça veut simplement dire être né sur le continent africain ET être citoyen d'un pays localisé sur le continent africain ET être de peau noire ? Si oui alors aucun astronaute/cosmonaute/spationaute ne répond pour le moment à ces critères.

J'ai corrigé l'explication sur Blueprint. Merci pour la remarque.

Voici la description des jeunes d'aujourd'hui qui est présente dans l'article :
"Ils regardent la télévision, mais juste pour leur série favorite. Ils ne lisent plus les journaux papier, sauf les gratuits parce qu'il suffit de les ramasser dans les transports en commun et que leurs articles sont courts. Ils ont tous un accès à Internet, souvent utilisé pour converser sur le réseau de socialisation Facebook."

je ne sais pas si c'est vrai ou pas mais franchement ça fait peur pour l'avenir. On se moque généralement du niveau culturel des américains qui sont incapables de citer la capitale de l'Italie ou de localiser le japon sur une carte...mais, si l'article dit vrai, on va avoir une génération de gens capable de citer les acteurs de la série Buffy contre les vampires mais de pas grand chose d'autre.

Je pense qu'il parle des mots clés évoqués dans le journal : "bill gates feynman lecture"

Je viens de tester et là le journal est en seconde position sur google.fr

Un communiqué de presse de Microsoft à ce sujet : http://www.microsoft.com/presspass/features/2009/Jul09/07-20(...)

Pas mal de marketspeak mais on note quand même un aveu ingénu : "Today’s release would have been unheard of from Microsoft a few years ago, but it’s a prime example that customer demand is a powerful catalyst for change.".

Ben oui c'est un peu le principe d'un marché libre que d'écouter le consommateur non ? Dommage que pour l'instant le consommateur desktop n'ai toujours que le droit de fermer sa gueule et d'acheter du Vista à la Fnac.

Si un juriste est dans la salle peut-être qu'il pourra nous expliquer qu'elles auraient été les conséquences de l'écriture de ce pilote si le noyau Linux été passé sous licence GPLv3.

Je crois me souvenir que la GPLv3 ajoute une clause de protection contre les attaques juridiques basées sur les brevets non ? Si Linux était sous la v3 est-ce que ce pilote écrit par Microsoft et incorporé au noyau signifierait que Microsoft perd automatiquement son droit à attaquer Linux pour violation de brevets ?
Si c'est bien le cas alors ça fout les boules d'être resté à la v2.....

Merci pour le lien. Effectivement après avoir lu ça on se rend compte que chez Brad ça frôle le pathologique....

Oh je ne doute pas que vous fassiez une distinction entre les bugs ayant des conséquences sur la sécurité et ceux n'en ayant à priori pas.
Le problème c'est que tu ne peux pas savoir si ceux que tu a mis dans le seconde catégorie ne relèvent pas en fait de la première...alors pourquoi dépenser de précieuses ressources à faire cette distinction qui n'a pas vraiment d'utilité ? Est-ce que ce n'est pas plus logique de dire aux utilisateurs d'appliquer toutes les corrections au lieu d'essayer de jouer au plus malin et de faire du pick and choose sur les correctifs ?

>>> C'est absolument faux, c'est tout a fait possible, simplement ca demande du boulot et un peu de temps

Cela a déjà été discuté as nauseam et manifestement les gens en charge des versions -stables du noyau ne sont pas du même avis que toi.

(créateur d'exploits) != (chercheurs en sécurité)

Un excellent commentaire d'Ingo Molnar à propos de la chronologie de cet exploit et surtout à propos de la personnalité (tordue) de Brad et des créateurs d'exploits.
Vraiment très intéressant à lire :

http://lwn.net/Articles/342163/