The author hesitated for a long time before publishing this article, because there are strong ethical issues. Documenting the effects of censorship can be seen as helping censors. For instance, if measurements show that censorship is very limited in practice, it may motivate some authorities to increase the pressure and its negative consequences. But I believe that censors are already better informed than the average citizen and that it is necessary to have factual information in order to have an informed debate in democracies.
Another big ethics issue concerns the measurements themselves. Is there a risk of endangering people who host a probe by doing DNS lookups for illegal/forbidden/questionable things (for instance DNS lookup for a porn site from a probe in Iran)? Today, the DNS is typically "under the radar" for most surveillance activities. Doing an HTTP request for an illegal site attracts attention to you in some countries (and it is one of the reasons why RIPE Atlas probes do not perform HTTP queries for arbitrary URLs), but it does not seem to be the case (yet) for DNS requests. (See RFC 7626, "DNS Privacy Considerations".)
— Permalien
Vous avez certainement déjà tout lu sur la vulnérabilité « Ghost » de la GNU libc (alias CVE-2015-0235). Si ce n'est pas le cas, vous pouvez vous documenter sur le blog du découvreur ou bien en lisant cette analyse technique ultra-détaillée. Mais un aspect de cette faille a été peu remarqué : qui diable utilise encore l'API gethostbyname, complètement dépassée ?
La faille se trouvait en effet dans une fonction nommée __nss_hostname_digits_dots qui est appelée par les fonctions, bien plus connues, gethostbyname et gethostbyaddr. Ces fonctions servent à traduire un nom de domaine en adresse IP, en général en faisant appel au DNS. Elles sont dépassées depuis longtemps et ne devraient plus être utilisées, notamment parce qu'elles ne permettent pas de faire de l'IPv6.
Ce point a bien été noté par les découvreurs de la faille (et, indépendamment, par certains sur les rézosocios), auteurs qui notent, dans le rapport technique, « The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead. ». En effet, en 2015, on n'imagine pas qu'il puisse exister des programmes qui se limitent volontairement à IPv4, en utilisant ces vieilles API.
Car ce n'est pas qu'une matière d'esthétique : les fonctions officiellement remplacées par des meilleures ne sont pas forcément aussi bien maintenues, et on peut penser que les failles n'y sont pas aussi vite repérées et corrigées. Les programmes utilisant les anciennes API ont donc plus de chance d'avoir des failles de sécurité comme Ghost.
Au fait, que faut-il utiliser depuis plus de quinze ans ? getaddrinfo, introduit à l'origine dans le RFC 2133 et actuellement normalisé dans le RFC 3493. (Vous trouverez mes exemples personnels dans mon article sur les structures de données réseau en C.) gethostbyname avait été marqué obsolescent dans POSIX en 2001 et supprimé complètement en 2008...
Aujourd'hui, si on cherche les « parts de marché » respectives de gethostbyname et getaddrinfo, on trouvera probablement qu'un grand nombre de programmes utilise toujours l'ancienne API. Ignorance, lecture de vieux HOWTO dépassés, cours jamais mis à jour...
Également à lire, sur Ghost :
Un très bon exposé de Bert Hubert parlant entre autres de la qualité du code DNS de la GNU libc et des nombreuses bogues qui s'y cachent, http://ds9a.nl/har-presentation-bert-hubert-3.pdf
Un article de Robert Graham qui dit la même chose que moi, http://blog.erratasec.com/2015/01/you-shouldnt-be-using-gethostbyname.html
Une excellente analyse technique de Ghost. http://lcamtuf.blogspot.fr/2015/01/technical-analysis-of-qualys-ghost.html
]]>Falcon is a minimalist WSGI library for building speedy web APIs and app backends. We like to think of Falcon as the Dieter Rams of web frameworks.
When it comes to building HTTP APIs, other frameworks weigh you down with tons of dependencies and unnecessary abstractions. Falcon cuts to the chase with a clean design that embraces HTTP and the REST architectural style.
— Permalien