Mais je suis toujours ahuri de constater à quel point les farfouilleurs qui publient des exploits se comportent comme des script kiddies alors qu'à la vue du code (de manière superficielle, je l'admets), cela semble d'un niveau correct (pour du C).
En effet, Ac1db1tch3z, notre tête de vainqueur au pseudonyme si inventif, parsème son code de logs contenant des messages de killer tels que :
__pppp_tegddewyfg("$$$ bl1ng bl1ng n1gg4 :PppPpPPpPPPpP\n");
__pppp_tegddewyfg("!!! y0u fuq1ng f41l. g3t th3 fuq 0ut!\n");
Ensuite, son code est obfusqué à coups de #define et nom de structures/variables/fonctions incohérents et l33tesques.
Est-ce que la réalité est aussi ridicule que le décrit l'excellent (sic-zenitramesque) film Hackers, peuplée de nolifes puérils à la Zero Cool, Crash Override, Angelina Jolie Acid Burn et autres IvanLeF0u ?
# fatche ça va être dur d'attendre vendredi
Posté par bubar🦥 (Mastodon) . Évalué à 10.
"c'est parceque n'importe quel gamin peux pirater linux"
ça, c'est fait.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par DLFP est mort . Évalué à 7.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par bubar🦥 (Mastodon) . Évalué à 4.
Question cinéma c'est normal d'après vous de préférer des films comme "Antitrust" et "Cypher", bien que considérés comme "b", plutot que "hacker" ?
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
Antitrust, ça m'a lourdé sévère.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Gregory Auzanneau (site web personnel) . Évalué à 9.
J'ai encore le souvenir au cinéma de voir des gens noter les adresses IP des satellites alors que les IP étaient en 10.*
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par vladislav askiparek . Évalué à 3.
Mais peut-être était-ce de l'IPV6....
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par alpentux . Évalué à 10.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Gniarf . Évalué à 5.
le mien c'est 127.0.0.1
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Laurent Cligny (site web personnel) . Évalué à 3.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Gniarf . Évalué à 2.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par j_kerviel . Évalué à 2.
Et la vue est sympa de là-haut ?
Il a peut être un tunnel ssh hein (il n'a pas dit quel port il utilisait) ;)
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par FReEDoM (site web personnel) . Évalué à 4.
Après cela devait être probablement sur le même principe que les numéros de téléphone qui commence toujours par 555 dans les films américains pour éviter de tomber sur de vrais numéros.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par 2PetitsVerres . Évalué à 2.
Et pourtant, on n'en est plus très loin...
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par FReEDoM (site web personnel) . Évalué à 2.
(mots clés IRIS cisco)
En règle générale la technologie mise en oeuvre dans les satellite à 20 ans de retard, cela doit être très éprouvé et très résistant aux conditions difficile que l'on trouvent là haut (ion lourds).
...
En fait tu as raison le java va bientôt être une technologie avec 20 ans de retards :)
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par FReEDoM (site web personnel) . Évalué à 3.
Désolé...
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par 2PetitsVerres . Évalué à 6.
Sinon certains satellites embarquent une JVM non activée en vol* qui permet de jouer des procédures de tests, principalement pour vérifier que tout est bien câblé.
Mais évidemment vu que ça existe, certains on l'idée pour de futurs programmes d'y mettre des trucs non vitaux...
* en même temps ils ne sont pas encore en vol ceux auxquels je pense, mais elle n'est pas censée être activée en vol
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par 2PetitsVerres . Évalué à 3.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par windu.2b . Évalué à 3.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Alex . Évalué à 2.
java n'étant qu'un fork raté de smalltalk, on peut l'envoyer dans l'espace depuis un bon moment deja
</on est vendredi et cest mon dernier jour de boulot>
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par FReEDoM (site web personnel) . Évalué à 4.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Dring . Évalué à 2.
C'est donc carrément prêt pour les satellites, maintenant.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par liberforce (site web personnel) . Évalué à 3.
Un spécialiste pour nous éclairer ?
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Krunch (site web personnel) . Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
- Tu travailles sur quoi ?
- Un algorithme de compression.
- mmmm (le gars observe l'algorithme pendant 3 secondes sans même toucher la souris) Waw, il c'est de l'excellent boulot !
Alors que tout le monde sait bien que faire du bon boulot en Java, c'est impossible…
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Joël . Évalué à 5.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par allcolor (site web personnel) . Évalué à 3.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par windu.2b . Évalué à 3.
Par contre, c'est du HTML qui défile dans le générique au début du film !
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par El Titi . Évalué à 4.
Mais pourquoi est-il si maichant ?
http://linuxfr.org/~ploum/27723.html
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par DLFP est mort . Évalué à 3.
Malheureusement, j'ai découvert la même chose, en PHP. Double (triple ?) peine.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Olivier Renaud . Évalué à 2.
[^] # Re: fatche ça va être dur d'attendre vendredi
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
"La première sécurité est la liberté"
# Arf :/
Posté par Maxime (site web personnel) . Évalué à 3.
[^] # Re: Arf :/
Posté par Nitchevo (site web personnel) . Évalué à 5.
Je pense que le lieu est idéal pour poser la question.....
[^] # Re: Arf :/
Posté par Axel . Évalué à 10.
[^] # Re: Arf :/
Posté par DLFP est mort . Évalué à 2.
[1] http://seclists.org/fulldisclosure/2010/Jun/302
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Arf :/
Posté par j_kerviel . Évalué à 5.
Il semblerait que notre ami n'en est pas à son premier coup d'essai
C'est peut être son deuxième coup d'essai :)
[^] # Re: Arf :/
Posté par passant·e . Évalué à 1.
Ce qui n'est pas plus mal, il passera moins de temps à lancer des floods où à jouer avec un botnet pour spamer son ex
Bon après on peut débattre s'il faut publier ou ps les exploits de cette manière...
Je trolle dès quand ça parle business, sécurité et sciences sociales
# il y a pire...
Posté par neologix . Évalué à 7.
Et bien récemment, un article sur LWN a évoqué un nouvel exploit dont il était l'auteur, mais cette fois c'est le délais de correction qui était souligné (près de 9 mois) : http://lwn.net/Articles/404043/
En lisant l'article, on a l'impression qu'il y a eu un raté dans la gestion du rapport de Brad :
Brad says that he first reported this problem in December, 2009, but got no response. More recently, he sent a note to Kees Cook, who posted a partial fix in response.
Mais en fait, dans les commentaires de l'article, on s'aperçoit que ce n'est pas aussi simple.
Greg Kroah-Hartman lui demande
Was this sent to the security contact for the kernel? I just searched
and could not find any notice sent to security@kernel.org from Brad
during that month.
If it was not sent there, where was it sent?
Ce à quoi Brad répond :
The context was I was already working with Ted on the ext4 bug, and since he was being responsive, chose to share some additional vulnerabilities with him.[...]With the general upstream attitude and handling of security bugs, on principle I don't email vendor-sec or security@.
Donc, Brad n'a pas soumis l'exploit à la mailing-liste chargée de la sécurité, et n'en a fait part à Ted Ts'o que parce qu'il le sentait réactif.
Encore pire, l'exploit avait déjà été corrigé dans grsec depuis un moment :
> I've also got two local DoS mm-related bugs to be fixed if you'd like to
> take a look at them. They exist in all 64bit kernels since 2.6.26 or
> so. The first is an easy fix (we've fixed it in grsec for some time),
> but the other one requires some more thinking and decision making (it's
> memory exhaustion that causes a complete lockup of the machine -- and
> the OOM killer is unaware of the memory because it's not
> associated/accounted for by any task).
Donc pour résumer, on a quelqu'un qui :
- rapporte des exploits quand ça lui chante
- ne les rapporte pas aux personnes concernées
- corrige les failles concernées dans dans grsec
Morale de l'histoire :
- Brad en a sûrement d'autre en réserves, qu'il réserve pour plus tard (à la Sergey Bubka)
- suivez les commits grsec, et vous verrez peut-être passer des patchs pour des failles non corrigées dans le noyau vanilla
[^] # Re: il y a pire...
Posté par Littleboy . Évalué à 9.
Moi aussi j'ai un compte LWN, je peux recopier l'article et les commentaires sans reflechir.
Critiquer le comportement de Brad sans connaitre l'historique, c'est profondement debile.
Entre les rapports de bugs ignores, les patchs sans attribution et les commits kernel dont les commentaires ont ete purges de toute historique et analyse de dangerosite, on comprend pourquoi il ne veut surtout pas perdre son temps avec ces gens la (dont certains le meprisent ouvertement)
Apres on peut discuter du bien fonde de sa demarche (et il n'est certainement pas exempt de tout reproche, loin de la). Mais passer sous silence tout cette historique, c'est etre d'une extreme mauvaise foi.
# Et c'est un francophone...
Posté par FReEDoM (site web personnel) . Évalué à 1.
#define VERT "\033[32m"
#define NORM "\033[0m"
#define BANNER VERT"Ac1dB1tCh3z "NORM"VS Linux kernel 2.6 kernel 0d4y\n"
# Mauvaise attribution
Posté par Bertrand Yvain . Évalué à 2.
* exploit for x86_64 linux kernel ia32syscall emulation (again)
* rediscovered by ben hawkes
* with help from robert swiecki and tavis ormandy
*
* original vulnerability discovered by Wojciech Purczynski
*
* original exploit by
* Robert Swiecki <robert_at_swiecki.net>
* Przemyslaw Frasunek <venglin_at_freebsd.lublin.pl>
* Pawel Pisarczyk <pawel_at_immos.com.pl>
*
* kernel priv escalation code borrowed from spender
*
*/
Mais :
/*
Ac1dB1tch3z Vs Linux Kernel x86_64 0day
Today is a sad day..
R.I.P.
Tue, 29 Apr 2008 / Tue, 7 Sep 2010
a bit of history:
MCAST_MSFILTER Compat mode bug found... upon commit! (2 year life on this one)
author David L Stevens <dlstevens@us.ibm.com>
Tue, 29 Apr 2008 10:23:22 +0000 (03:23 -0700)
committer David S. Miller <davem@davemloft.net>
Tue, 29 Apr 2008 10:23:22 +0000 (03:23 -0700)
This patch adds support for getsockopt for MCAST_MSFILTER for
both IPv4 and IPv6. It depends on the previous setsockopt patch,
and uses the same method.
Signed-off-by: David L Stevens <dlstevens@us.ibm.com>
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
------------------------------------------------------------
Thank you for signing-off on this one guys.
This exploit has been tested very thoroughly
over the course of the past few years on many many targets.
Thanks to redhat for being nice enough to backport it into early
kernel versions (anything from later August 2008+)
Ac1dB1tch3z would like to say FUCK YOU Ben Hawkes. You are a new hero! You saved the
plan8 man. Just a bit too l8.
PS:
OpenVZ Payload / GRsec bypass removed for kidiots and fame whores. (same thing right ;))
*/
[^] # Re: Mauvaise attribution
Posté par DLFP est mort . Évalué à 2.
La version compréhensible par les humains : http://www.theregister.co.uk/2010/09/15/linux_kernel_regress(...)
Les gens qui utilisent grsec et/ou compilent leur noyau avec une config personnalisée seront intéressés par ceci : http://marc.info/?l=gentoo-hardened&m=128467193314300&am(...)
Bref si vous n'avez pas CONFIG_IA32_EMULATION activé, vous ne risquez rien.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Mauvaise attribution
Posté par FReEDoM (site web personnel) . Évalué à 2.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.