Service de stockage en ligne libre et respectueux de la vie privée en financement participatif

Posté par  . Édité par Nils Ratusznik, Nÿco, tuiu pol et Bruno Michel. Modéré par Nÿco. Licence CC By‑SA.
Étiquettes :
15
26
mai
2014
Internet

La jeune société Lupo Libero SASU vient de lancer une campagne de financement participatif pour développer un service de stockage de fichiers en ligne, type Dropbox ou Google Drive, en logiciel libre (licence MIT) et avec un très haut niveau de protection de la vie privée. Il n'y a donc pas encore de code source disponible.

Ce service permettrait dans un premier temps de :

  • stocker des fichiers et répertoires, pour archivage ou pour y accéder à distance ;
  • partager ces données (photos, vidéos, etc.) avec d'autres personnes ;
  • synchroniser son espace en ligne avec un répertoire de son ordinateur.

À la différence de nombreux services concurrents, les fichiers seront chiffrés (= verrouillés) sur l'ordinateur de l'utilisateur, avant d'être envoyés sur les serveurs. Ainsi une personne accédant légitimement (ex : un administrateur) ou non (ex : un pirate) aux serveurs ne pourra y obtenir des informations sur la vie privée des utilisateurs.

La libération et la sécurisation du stockage en ligne grand public est la première étape du projet Lupo Libero. L'objectif n°2 sera probablement de concurrencer Facebook. Et un peu plus loin dans notre feuille de route l'on peut trouver : "révolutionner internet".

Les personnes intéressées trouveront plus d'informations en lisant le (long) texte de présentation de la campagne de financement sur le site Indiegogo (lien ci-dessous). Si vous souhaitez suivre ce projet, il y a une page Twitter et une page Facebook.

Journal Computrace, une backdoor pour votre plus grand bien

Posté par  . Licence CC By‑SA.
Étiquettes :
47
20
mai
2014

Bon journal ? En tout cas mauvaise nouvelle.

Il y a de ça quelques mois, la société Kaspersky découvre un logiciel malveillant installé sur au moins 2 millions d'ordinateurs.
Computrace se divise en 3 modules présents dans l'option ROM PCI qui est chargée ensuite par le BIOS de la machine.

Par la suite il est capable :

  • De sécuriser les données d'un parc de postes à distance
  • De déployer toujours à distance des mises à jour, des licences ou de lancer (…)

Suivi — Tribune Faille dans la tribune

#1355 Posté par  . État de l’entrée : corrigée. Assigné à Bruno Michel. Licence CC By‑SA.
Étiquettes :
7
22
mai
2014

Il y a une petite faille dans la tribune qui permet de poster à peut prêt n'importe quelle balise dans un post à partir du moment où il y a une norloge dedans. Par exemple, le post suivant permet de récupérer un pseudo cookie

00:00:00<form method="post"><input id="input-chauve" name="board[message]" type="hidden" value="plop"><input type="submit" onclick="var coo = ''; for (var i=0; i<20; ++i) { coo+= Math.floor(Math.random() * 10); } document.getElementById('input-chauve').value = 'mon cookie est ' + coo"></form>

C'est valable sur toutes les tribunes (…)

Journal Les macarons, pour remplacer les cookies

Posté par  (site web personnel, Mastodon) . Licence CC By‑SA.
Étiquettes :
21
19
mai
2014

Aujourd'hui, sur le Web, l'authentification de chaque requête HTTP, une fois passée le "login" initial, se fait presque toujours avec un cookie, une série de bits générée par le serveur et qu'un éventuel attaquant ne pourrait pas deviner. Les cookies ont plusieurs limites, notamment parce qu'ils sont tout ou rien. Si je passe un cookie à un tiers (volontairement ou bien parce que la session n'était pas bien protégée), ce tiers a exactement les mêmes droits que moi. Des chercheurs (…)

Concours sécurité sur LinuxFr.org : 3 livres à gagner !

Posté par  (site web personnel, Mastodon) . Édité par palm123, Benoît Sibaud et Nils Ratusznik. Modéré par claudex.
Étiquettes :
35
28
avr.
2014
Sécurité

La sécurité et la vie privée sont des sujets de plus en plus récurrents et sensibles, maintenant aussi aux yeux de la presse généraliste et du grand public depuis les informations fournies par Edward Snowden. Le flot continu de révélations ne calmera pas la situation de sitôt. Mais il n'y a pas que E.Snowden qui fait l'actualité en sécurité informatique, c'est aussi la faille Heartbleed dans OpenSSL et son impressionnante taxonomie, la fin de la liste Full Disclosure, etc. l'actualité sur le sujet ne manque pas. Si tout n'est pas parfait chez LinuxFr.org, nous tâchons de montrer l'exemple. Pour vous inciter à partager encore plus sur le sujet, nous vous proposons de gagner un des trois exemplaires du livre Hacking, sécurité et tests d'intrusion avec Metasploit (édité par Pearson), en espérant aussi que cela vous sensibilisera et vous permettra de monter en compétence sur ces sujets essentiels.

Hacking, sécurité et tests d'intrusion avec Metasploit

Bonne chance !

« Triple poignée de main », faille dans le protocole TLS

Posté par  . Édité par BAud, Thierry Thomas, Nÿco, Benoît Sibaud, palm123, dourouc05, Florent Zara et olivierweb. Modéré par Florent Zara. Licence CC By‑SA.
Étiquettes :
55
9
mai
2014
Sécurité

Après les deux failles mettant en cause l’utilisation d’instructions goto (l’une chez Apple, l’autre chez GNUTLS) et la faille Heartbleed, une vulnérabilité a encore été découverte : Triple Handshake («Triple poignée de main»), aussi appelée 3Shake.

Contrairement aux autres failles, celle-ci ne concerne pas l’implémentation mais le protocole. Cela signifie qu’elle touche potentiellement toutes les implémentations et que la correction définitive de cette faille nécessiterait une modification dans le protocole. En pratique, les corrections ont été effectuées en faisant des vérifications supplémentaires ou en éliminant certains algorithmes de chiffrement.
Logo de 3Shake, inspiré de celui de Heartbleed
Logo par @Raed667
Concrètement, cette faille exploite les différents types de poignées de main (handshake, procédure qui permet d’établir les différents paramètres de communication entre deux machines, étape particulièrement importante pour un protocole de sécurité) afin de se faire passer pour une autre machine et d’effectuer une attaque de l’homme du milieu.

La faille est cependant considérée moins grave que Heartbleed, en partie parce qu’elle est compliquée, s’attaque à une configuration assez spécifique et nécessite une position privilégiée entre deux machines.

OpenJDK JEP 180: HashMap, collisions & attaques par la complexité

Posté par  . Édité par claudex, palm123, Benoît Sibaud, Nils Ratusznik et ZeroHeure. Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
46
6
mai
2014
Java

Cette dépêche parle de la JEP 180 d'OpenJDK 8 qui propose une solution intéressante aux problèmes d'attaques sur la complexité que rencontrent les tables de hachage.

On a déjà parlé de ce sujet ici même à plusieurs reprises. Je vais cependant rapidement représenter le problème et l'évolution des discussions. Le lecteur averti sur le sujet ira directement au dernier paragraphe pour voir la proposition de la JEP 180.

NdM : merci à ckyl pour son journal.

Journal Seccomp, une sandbox intégrée au noyau Linux…

Posté par  . Licence CC By‑SA.
Étiquettes :
45
4
mai
2014

Problématique

Utilisez-vous pour vos développements professionnels ou privés une solution d'intégration continue à la Jenkins ? Un tel logiciel permet d'accélérer le développement du code en le testant plus régulièrement, en le soumettant automatiquement à des tests unitaires.

Mais que se passe-t-il si un vilain© soumet du code dangereux pour votre système d'intégration continue ? Si votre logiciel d'intégration continue se contente de compiler du code, vous pensez qu'il est protégé ? Quid d'une faille dans votre compilateur, ou d'un problème à l'exécution (…)

Journal Heartbleed : petit best of des journalistes

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
70
11
avr.
2014

Aaah, pas facile d'écrire un article sur un sujet aussi technique que le récent bug sur OpenSSL, baptisé Heartbleed, quand on est journaliste généraliste. Forcément, ça donne des erreurs et approximations dans l'article final, ce qui ne manque pas de nous font osciller entre le rire gras et le désespoir, nous, techniciens. Petit tour d'horizon du best of des journalistes sur Heartbleed.

Avant de commencer, notons que je passerai sur les trop nombreuses occurrences de l'adjectif crypté et ses variantes (…)

Forum Linux.debian/ubuntu Mis à jour automatique VPS Debian, faille de sécurité ?

Posté par  . Licence CC By‑SA.
Étiquettes :
0
29
avr.
2014

Bonjour,

Suite à quelques commentaires postés dans les forums j'essaye en ce moment le principe de VPS avec Iniz :

Je suis donc parti sur une VM Debian Wheezy et j'ai regardé un peu comment cela se passait.

Pas de gros soucis, c'est en gros comme une Debian que l'on installe soi-même sauf que :

  1. il y des limitations sur iptable à cause de la virtualisation: Issues with Ubuntu's UFW on OpenVZ VPS
  2. les droits d'exécution ont été (…)

Journal Full Disclosure, le retour

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
10
23
avr.
2014

Il y a peu, Xavier nous apprenait que Full Disclosure, c'est fini.

Pourtant, devant les mouvements générés par cette annonce, une part de la communauté s'est organisé, et Full Disclosure a un nouveau départ.

Fyodor reprend donc le flambeau de John Cartwright pour colporter les idéaux d'une sécurité transparente, jusque dans la publication des nouvelles failles.

Longue vie à Full Disclosure, et n'hésitez-pas à vous inscrire si vous l'étiez sur l'ancienne.

Journal Qualité du logiciel : le logiciel libre est bien meilleur que le propriétaire !

Posté par  . Licence CC By‑SA.
Étiquettes :
34
17
avr.
2014

Le rapport 2013 de Coverity est sorti

http://www.ciol.com/ciol/features/213112/coverity-scan-report-source-software-quality-outpaces-proprietary-code

Coverity propose un service de vérification de code par analyse statique. Depuis 2008, ils testent à grande échelle des logiciels libres et comparent les statistiques à leur large base de clientèle reposant sur du logiciel propriétaire. Il s'agit majoritairement de programmes C/C++.

Régulièrement, la qualité du logiciel libre est mise en avant et surpasse celle du logiciel propriétaire, selon leur métrique de nombre de problèmes trouvés par coverity par 1000 lignes de (…)

Journal journal bookmark : vers un fork d'OpenSSL ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
55
15
avr.
2014

Bonjour Nal,

je t'écris pour te faire part d'un possible fork d'OpenSSL par les développeurs d'OpenBSD qui ont démarré depuis quelques jours un nettoyage complet.

Entre autres :

  • suppression des fonctionnalités heartbeat qui ont conduit au bug de la semaine dernière;
  • suppression de beaucoup de code cryptographique en trop;
  • suppression de wrappers autour de fonctions standard, en particulier pour malloc qui entravait des techniques de mitigation d'exploit

et autres nettoyages divers (cf premier lien), ce qui vu de loin (…)

Nouvelle vulnérabilité dans l’implémentation OpenSSL

Posté par  . Édité par Davy Defaud, Benoît Sibaud, Lucas Bonnet, Bruno Michel et claudex. Modéré par Ontologia. Licence CC By‑SA.
Étiquettes :
86
8
avr.
2014
Sécurité

Une vulnérabilité dans l’implémentation de l’extension heartbeat (RFC 6520) d’OpenSSL a été découverte conjointement par une équipe de chercheurs en sécurité (Riku, Antti and Matti) à Codenomicon et Neel Mehta de Google Securité. On retrouve ici un vieux bogue des familles : le read overrun.

OpenSSL 1.0.1, jusqu’à 1.0.1f inclus, et OpenSSL 1.0.2-beta1 sont affectés. Ce sont les versions utilisées dans la plupart des distributions.

Cette dernière permet la lecture de 64 Kio dans la mémoire des clients et serveurs affectés (mais l’attaque peut être rejouée à chaque heartbeat), autorisant la lecture de données comme les clés privées et, bien sûr, les données échangées une fois ces dernières retrouvées (et ce, même en mode hors ligne s’il n’y avait pas de forward secrecy utilisé).

Il est difficile, voire impossible, de faire une détection post‐mortem d’infiltration, l’attaque ne laissant pas d’entrée suspecte dans le journal système.

Passer à OpenSSL 1.0.1g, redémarrer tous les services utilisant libssl et remplacer l’intégralité de ses certificats (la clef privée étant vulnérable) est donc nécessaire.