Utilise un compilateur obsolète un risque de sécurité ?

Question

Nous avons un certain de construire des systèmes de production qui n'intéresse personne et ces machines anciennes versions de GCC comme GCC 3 ou GCC 2.

Et je ne peux pas convaincre la gestion de la mettre à niveau vers une plus récente: ils disent, "si ce n'est pas cassé, ne le répare pas".

Depuis que nous avons le maintien d'une très ancienne base de code (écrit dans les années 80), ce C89 code se compile très bien sur ces compilateurs.

Mais je ne suis pas sûr que c'est une bonne idée d'utiliser ces vieux trucs.

Ma question est:

On peut utiliser un vieux compilateur C de compromettre la sécurité du programme compilé?

Mise à JOUR:

Le même code est construit par Visual Studio 2008 pour Windows cibles, et MSVC ne prend pas en charge C99 ou C11 encore (je ne sais pas si une version plus récente MSVC), et je peux m'appuyer sur mon Linux à l'aide de la dernière version de GCC. Donc, si nous suffit de les déposer dans une version plus récente de GCC, il serait probablement construire tout aussi fine qu'avant.

Answer 1

En fait, je dirais le contraire.

Il y a un certain nombre de cas où le comportement n'est pas défini par la norme, mais où il est évident que ce serait le cas avec un "bête compilateur" sur une plate-forme donnée. Des cas comme permettant à un nombre entier signé de débordement ou de l'accès à la mémoire même si les variables de deux types différents.

Les versions récentes de gcc (et clang) ont commencé à traiter ces cas comme l'optimisation des possibilités de ne pas s'en occuper s'ils changent la façon dont le binaire se comporte dans le "comportement indéfini". C'est très mauvais si votre base de code a été écrit par des gens qui ont traité C comme un "assembleur portable". Comme le temps passait, les optimiseurs d'avoir commencé à regarder de plus en plus gros morceaux de code pour faire des optimisations d'augmenter la chance de le binaire de faire autre chose que "ce qu'un binaire construit par un monte-compilateur" allait faire.

Il y a des commutateurs du compilateur pour restaurer "traditionnel" des comportements (-fwrapv et -fno-strict-aliasing pour les deux je l'ai mentionné ci-dessus) , mais d'abord vous devez savoir à leur sujet.

En principe, un bug du compilateur pourrait se transformer conforme code dans un trou de sécurité je considère le risque d'être négligeable dans le grand schéma des choses.

Answer 2

Il y a des risques dans les deux cours de l'action.

---

Les compilateurs plus âgés ont l'avantage de la maturité, et tout ce qui était cassé dans leur a probablement (mais il n'y a pas de garantie) été contourné avec succès.

Dans ce cas, un nouveau compilateur, est une source potentielle de nouveaux bugs.

---

D'autre part, les nouveaux compilateurs venir avec supplémentaire de l'outillage:

• GCC et Clang les deux proposent maintenant des produits désinfectants qui peuvent instrument le moteur d'exécution pour détecter des comportements indéfinis de différentes sortes (Chandler Carruth, de la Google Compilateur de l'équipe, a revendiqué l'année dernière qu'il attend d'eux qu'ils ont atteint une couverture complète)
• Clang, au moins, les caractéristiques de durcissement, par exemple de Flux de Contrôle d'Intégrité est au sujet de la détection hi-prises de contrôle de flux, il y a aussi le durcissement met en œuvre pour la protéger contre l'écrasement de la pile attaques (en séparant les flux de contrôle partie de la pile de la partie données); renforcement de la protection de fonctionnalités sont généralement à faible charge (< 1% de charge du CPU)
• Clang/LLVM est également de travailler sur libFuzzer, un outil pour créer des instrumenté fuzzing unité-tests qui explorent l'espace d'entrée de la fonction de l'essai intelligemment (en jouant sur l'entrée pour prendre le pas-comme-encore exploré les chemins d'exécution)

Instrumentant de votre binaire avec les désinfectants (Adresse de Désinfectant, de la Mémoire de Désinfectant ou d'un Comportement Indéfini Désinfectant) et puis le fuzzing (à l'aide de l'Amérique Fuzzy Lop par exemple) a permis de découvrir des vulnérabilités dans un certain nombre de haut profil des logiciels, voir par exemple cet LWN.net l'article.

Ces nouveaux outils, et tous les futurs outils, sont inaccessibles pour vous, sauf si vous mettez à niveau votre compilateur.

En restant sur une faible puissance de compilateur, vous mettez votre tête dans le sable et croise les doigts qu'aucune vulnérabilité est détectée. Si votre produit est une cible de grande valeur, je vous invite à reconsidérer.

---

Remarque: même si vous n'avez PAS de mise à niveau de la production compilateur, vous pourriez vouloir utiliser un nouveau compilateur de vérifier la vulnérabilité de toute façon; sachez que, depuis ceux qui sont différents compilateurs, les garanties sont moindres.

Answer 3

Votre code compilé contient des bugs qui pourrait être exploité. Les bugs viennent de trois sources: des Bugs dans votre code source, des bugs dans le compilateur et les bibliothèques, et à un comportement indéterminé dans votre code source que le compilateur se transforme en un bogue. (Comportement indéfini est un bug, mais pas d'un bogue dans le code compilé encore. Comme un exemple, i = i++; en C ou C++ est un bug, mais dans le code compilé, il peut augmenter i de 1 et être Ok, ou un ensemble i de l'ordure et être un bug).

Le taux de bogues dans le code compilé est probablement faible en raison des tests et à la correction des bugs due à la clientèle des rapports de bogues. Donc, il peut y avoir un grand nombre de bugs au début, mais qui a baissé.

Si vous mettez à niveau vers un nouveau compilateur, vous risquez de perdre des bugs qui ont été introduites par le compilateur de bugs. Mais ces bugs seraient tous les bugs que, à votre connaissance, personne n'a trouvé et personne ne exploitées. Mais le nouveau compilateur peut avoir des bugs sur son propre, et surtout plus récents, les compilateurs ont une plus forte tendance à tourner un comportement indéterminé en bugs dans le code compilé.

Ainsi, vous aurez tout un tas de nouveaux bugs dans le code compilé; tous les bugs que des pirates pourraient trouver et d'exploiter. Et, à moins de faire beaucoup de tests, et de laisser votre code avec les clients afin de trouver des bugs pendant une longue période, il sera moins sécurisé.

Answer 4

Si il n'est pas cassé, ne le répare pas

Votre patron sonne juste en disant cela, cependant, le plus important facteur, est la sauvegarde des entrées, des sorties, des débordements de tampon. L'absence de celles-ci est toujours le maillon faible de la chaîne à partir de ce point de vue, quel que soit le compilateur utilisé.

Cependant, si le code de base est ancienne, et le travail a été mis en place pour atténuer les faiblesses du K&R C utilisés, tels que le manque de sécurité de type, l'insécurité, le fgets, etc, peser la question "Serait la mise à niveau du compilateur, plus moderne C99/C11 normes de tout casser?"

À condition, qu'il y a clairement un chemin de migrer vers les nouvelles normes C, ce qui pourrait induire des effets secondaires, peut-être préférable de tenter une fourchette de l'ancienne base de code, d'évaluer et de mettre en extra de type vérifications, des contrôles d'intégrité, et de déterminer si la mise à niveau vers le nouveau compilateur a aucun effet sur l'entrée/sortie des ensembles de données.

Ensuite, vous pouvez montrer à votre patron",Voici la mise à jour de la base de code, refactoring, plus en ligne avec l'industrie a accepté le C99/C11 normes...".

C'est le pari qui aurait à être pesée, très soigneusement, la résistance au changement peut montrer qu'il y dans l'environnement et peut refuser de toucher le plus récent des trucs.

MODIFIER

Juste assis en arrière pendant quelques minutes, réalisé beaucoup, K&R code généré peut être en cours d'exécution sur un 16bit plate-forme, les chances sont, mise à niveau, plus moderne compilateur pourrait briser le code de base, pense en termes d'architecture 32 bits de code généré, ce qui pourrait avoir de drôles d'effets secondaires sur les structures utilisées pour les entrées/sorties ensembles de données, qui est un autre énorme facteur à peser soigneusement.

Aussi, depuis l'OP a mentionné l'aide de Visual Studio 2008 pour créer la base de code, en utilisant gcc pourrait induire la mise en de l'environnement MinGW ou Cygwin, qui pourraient avoir un impact du changement sur l'environnement, sauf si la cible est pour Linux, alors il sera vaut le coup, peut-être incluent des commutateurs supplémentaires pour le compilateur pour réduire le bruit sur les vieux K&R d'une base de code, l'autre chose importante est de réaliser un grand nombre de tests pour s'assurer qu'aucune fonctionnalité est cassé, peut-être un exercice pénible.

Answer 5

On peut utiliser un vieux compilateur C de compromettre la sécurité du programme compilé?

Bien sûr, il peut, si l'ancien compilateur contient des bugs connus que vous connaissez pourraient nuire à votre programme.

La question est, est-il? Pour en être sûr, vous avez lu le journal de modification de votre version à jour et vérifier chaque correction d'un bug au fil des ans.

Si vous ne trouvez pas la preuve de compilateur bugs qui pourraient nuire à votre programme, la mise à jour de GCC juste pour le plaisir, il semble un peu paranoïaque. Vous devez garder à l'esprit que les versions plus récentes peuvent contenir des bugs, qui ne sont pas encore découvert. Beaucoup de changements ont été apportés récemment avec GCC 5 et C11 soutien.

Cela étant dit, le code écrit dans les années 80 est probablement déjà rempli à ras bord avec des trous de sécurité et de confiance en mal définis comportement, peu importe le compilateur. Nous parlons de la pré-norme C ici.