pasBill pasGates a écrit 16062 commentaires

Terminal Services...

Ah, ben alors ca doit etre uniquement quand tu join un domain a l'install, moi y en a m'etre trompe :+(

Le virus qui s'execute en local, que tu sois root avec un password hyper complexe, user avec un password hyper-complexe ou user dugland sans password, sur Windows ou Unix ca change rien, car il a pas besoin de s'authentifier une fois qu'il est sur ta machine, il accede directement a tous tes fichiers.

Par contre un virus pourrait essayer de faire un su(ou runas.exe) en utilisant un blank password pour attaquer d'autres comptes.

Sous XP si le virus essaye de faire ca sur un compte sans password, il n'y arrivera pas.

Decompiler et comprendre le code machine d'un virus(qui d'habitude contient tres peu de code), le passer a travers un debugger pour voir ce qu'il fait pas a pas, ne demande pas des genies, simplement des gens competents, et chez les societes d'AV, il y en a des gens competents.

Et sinon, ces societes ont pour la plupart des reseaux heterogenes avec un grand nombre d'OS differents(et de versions differentes), on en a aussi pour tester l'interop reseau, ils en ont surement aussi pour zieuter les modes de transmission de virus.

Non il n'y a pas d'avertissement.

Par contre XP(pas 2000) limite l'acces aux comptes sans passwords.
Il est uniquement possible de se logger sur la console avec un compte sans password(en gros: faut etre devant la machine), pas d'acces depuis le reseau, pas depuis runas.exe,...

Non non, a la fin de l'install de Windows 2000 Pro(pas server/adv server), tu peux ajouter des utilisateurs a ton systeme, mais tu as le choix du groupe dans lequel tu les mets(dans un drop down menu), t'es pas oblige de les mettre dans le groupe admin.

Sous Windows tout le monde a tous les droits.

C'est faux.

P*tain de bordel de m*, je vais me mettre moi aussi a sortir des conneries de ce niveau sur Linux, on va voir combien de temps je tiens avant de me faire incendier comme quoi je fais du FUD, mensonges, propagande,...

T'as presque mais pas bon.

Si tu l'execute en user il infectera les binaires sur lequels ton user a le droit d'ecrire.

Et le jour ou tu lanceras un de ces binaires en etant root, hop le virus se lance et il a acces a toute ta machine car le binaire tourne alors avec les droits root.

C'est vrai que su est mis bien plus en avant dans Linux, t'as des pop-ups qui s'affichent partout toutes les 5 minutes pour te rappeler que su existe.

Non ?

Toi tu lis pas souvent linuxfr.org, ca doit bien faire la 585eme fois que je le dis:

runas.exe, en command line.

Administration a distance:

- WMI
- notre chere MMC(qui utilise entre autres WMI)
- group policies (qui permettent de definir des comportements/regles pour toutes les machines d'un domaine)
- un peu de wsh/vbscript quand c'est necessaire
- MSI pour packager les softs a installer sur les systemes
...
- SMS si tu veux faire encore plus, mais c'est un soft a part

Le truc que les gens comprennent pas c'est que sous Linux l'admin a distance passe le plus frequemment par telnet/ssh en se connectant sur la machine, sur Windows elle passe par DCOM et les permissions de domaine qui font que tu as un soft/script sur une machine, et tu diriges tout depuis la, sans avoir a te logger sur la machine cible, c'est une approche differente.

Backup ?
Tu mets les profiles des utilisateurs sur un serveur(en gros ca revient a exporter /home en NFS), que tu backup avec l'outil que tu veux, la plupart permettent de faire des backups a intervalles reguliers.

Ce truc la ne sert qu'a une chose: te proteger si tu te trompes.
Si tu te trompes pas en ecrivant ton allocation, ca sert a rien bien evidemment, mais le probleme est que tout le monde se trompe avec ca, et c'est une des causes les plus frequentes de buffer overflow.

Si t'as oublie un mutex sur ton tampon, c'est une erreur ! Mais le fait de specifier la taille du buffer a l'ecriture(strncpy) fait que tu n'auras pas un buffer overflow, peut-etre un autre probleme mais potentiellement moins grave.

Quand a strdup, c'est bien joli mais c'est le genre de truc a finir avec des memory leaks ca et ca fragmente monstrueusement ta memoire, faut a chaque fois allouer/desallouer, chaque allocation que tu fais est un risque de plus d'oublier de desallouer, c'est un test de plus a faire pour voir si malloc a fonctionne,...

C'est pas faisable pour des serveurs, c'est beaucoup trop lourd.

Tiens c'est marrant tout ce que tu nous decrit est realisable sans problemes sous Windows :+)

Je rappelles que quand on est capable d'ecrire des scripts sous Linux, on les ecrit.

Et quand on est capable d'ecrire des scripts sous Windows on les ecrit aussi.

Le fait que tu ne connaisse rien aux capacites de script de Windows(vbscript,wsh,wmi,...) ne signifie pas que c'est le cas de tout le monde, et le fait qu'un OS soit scriptable ne signifie pas que tout le monde sait l'utiliser ainsi.

Oui ben on a donc la meme definition de tampon "dynamique".

Ca ne resoud RIEN DU TOUT.

Un tampon dynamique c'est super si tu ne te trompes jamais dans le calcul de la taille de l'allocation, si tu peux te permettre de faire des allocations toutes les secondes(et un malloc est une des operations les plus lentes), ...

Le probleme que t'as du mal a voir il me semble est le suivant:

1) Cas avec tampon dynamique et strcpy
Tu alloues un buffer dynamiquement, tu calcules sa taille comme tu veux, et apres tu fais ta copie SANS AUCUNE VERIFICATION A CE STAGE

Resultat: Si tu t'es gourre dans la taille du buffer, tu t'ecrases

2) Cas avec tampon dynamique et strncpy
Tu alloues un buffer dynamique, tu calcules sa taille comme tu veux, et apres tu fais ta copies en specifiant la taille du buffer.

Resultat: TU ES SUR DE NE PAS DEPASSER LE BUFFER, meme si tu t'es gourre dans le calcul de la taille du buffer, meme si un autre thread change la taille du string,..., car quoi qu'il arrive, tu n'ecriras pas plus loin que la fin du buffer.

Non serieux, tu peux demander a n'importe quel gourou securite, si tu lui dis les mots strcpy et strcat, il va prendre un air affole et appeler le ciel a l'aide. Chez nous utiliser strcpy ou strcat c'est considere "bad practice", et dans tout element un tant soit-peu sensible de l'OS(service, truc qui a des droits eleves,...) c'est un BUG, et on est loin d'etre les seuls a faire de la sorte.

Ces gens la n'ont semble t'il jamais eu a l'esprit que le prix de 250 licences n'est pas identique a 250 fois le prix d'une licence au magasin d'a cote, les prix baissent enormement lorsque l'achat est gros, et ca fausse enormement les resultats.

Finalement, rien la dedans ne parle de l'impact sur ce que les decideurs appellent la "productivite" des employes.
Est-ce que les gens sont aussi efficaces avec OpenOffice/Gimp/... que avec Office XP/Photoshop/... ?

De la meme maniere, leur calcul ne mesure pas sur la duree, si par hasard les gens sont moins productifs, sur 3 ans ca pese lourd, le prix des softs aussi devient moins important si le hardware est renouvelle et pas le soft, etc...

Ca aussi ca entre dans le TCO, et ca manque cruellement dans leur "etude".

Alors c'est quoi un tampon qui n'a pas de taille fixe ?

J'ai du mal a te suivre la(un petit exemple aiderait je pense).

Sinon, strdup est bien joli, mais il alloue a chaque fois de la RAM, pas tres utilisable.

Meuh non je me suis pas gourre dans mon 3eme argument :+)

char buffer[400+1];

buffer[400]=0; // 401eme element

strncpy(buffer,thestring,400); // --> de 0 a 399

Le risque d'erreur est la effectivement, mais c'est pour ca que tu fais :

- allouer un buffer de taille size+1, pas de reflexion a faire tu fais aveuglement un +1 a chaque fois.

Ensuite tu sais qu'il ne faut pas mettre le +1 dans ton 3eme parametre.

un petit define:
#define STACK_BUF(TYPE, NAME, SIZE) TYPE NAME[SIZE+1];

et ca donne:

STACK_BUF(char, buffer, 400);

MyStrnCpy(buffer,thestring, 400);

La tu ne t'occupes plus de rien d'autres que d'un seul chiffre, plus besoin de chercher des histoires de +1, -1, etc...

strcpy, strcat,... sont DANGEREUX.

Ton tampon peut etre alloue dynamiquement ca change rien. Si tu te trompes sur la taille de l'allocation ou si le string que tu passes n'as pas de '0' a la fin(bon ok c'est plus un string a ce moment...) tu risques un heap overflow et c'est aussi dangereux qu'un stack overflow(bien qu'un peu moins facile a exploiter, mais tres loin d'etre infaisable).

La regle c'est de limiter la copie a la taille du buffer, et ca tu peux pas le faire avec un strcpy ou un strcat. strncpy et strncat resolvent en partie ce probleme bien qu'ils ne soient pas parfait a 100%, mais c'est deja une tres grosse avancee.

Si tu as:

char *monbuffer=(char*)malloc(SIZE+1);
//test alloc success
strcpy(monbuffer,thestring);

- T'as un BO si thestring n'est pas null terminated
- T'as un BO si tu t'es gourre de taille pour SIZE

si tu utilises

#define MyStrnCpy(X,Y,Size) X[Size]=0; \
strncpy(X,Y,Size);

MyStrnCpy(monbuffer, thestring, SIZE);

Tu elimines ces 2 risques.

Faut bien comprendre qu'aucune fonction sans bug n'est dangereuse d'elle meme, une fonction est dangereuse a partir du moment ou le dev l'utilise mal en lui passant des parametres a la con.
strncpy et strncat sont plus surs car en utilisant la simple technique de:
- allouer un buffer de <size>+1
- mettre buffer[size] a 0 avant l'appel a strncpy
- specifier le nombre max de char a copier

On est sur de ne pas eclater le buffer.

Ces etapes sont elles aussi sujettes a erreur, mais elles sont beaucoup plus simples a effecteur et bien moin sujettes a erreur que faire un strcpy en priant pour qu'on ne se soit pas trompes en calculant la taille du buffer.

Mieux encore:

Si tu ne fais jamais d'erreur, tu ne te trompes jamais dans l'index de ta boucle, sur la taille de tes elements,... et bien tu n'as aucun buffer overflow dans ton code non plus.

Tout le probleme est que les gens font toujours des erreurs, et aucun papier quel qu'il soit ne changera ca, alors les GNU coding standards c'est bien joli, mais ca resoud rien du tout. ca elimine quelque cas mais c'est tout.

En passant, je suis tres loin de penser qu'il faudrait eliminer C/C++(bien au contraire), le jour ou d'autres langages auront le meme rapport temps de dev/performance/flexibilite n'est pas encore arrive.

T'as oublie d'envoyer la meme pour Sony et Nintendo qui vendent eux aussi a perte.

Quand a ton truc sur les licences OEM, je vois pas trop ce que ca a a voir avec la xbox mais bon...

Quelles fenetres cachees ?

Eclaires moi donc...

Le pirate n'a jamais eu acces aux sources, il avait pose un trojan sur la machine d'un blaireau en lui envoyant un e-mail avec le genre d'attachements sur lequels il faut pas clicker si t'as un cerveau, mais ce gars n'avait pas acces aux sources.
L'avantage ici est que seuls les developpeurs ont acces aux sources, et d'habitude eux ils savent qu'il faut pas clicker sur kournikova.jpg.exe

La difference etant que Nullsoft ne garde pas les sources de ses softs sur un site web qui est bien plus facile a hacker qu'un serveur interne dans une entreprise auquel la plupart des employes n'ont pas acces.

Ca c'est un petit desavantage de l'open source pour ce genre de cas, acceder aux sources pour les modifier et enormement plus complique dans le cas d'un soft proprio car les sources sont souvent gardees bien a l'abri du fait que les auteurs ne veulent pas le partager.

odbc32.dll je vois pas quel probleme il pose, si un utilisateur le lance, odbc32.dll tournera avec les droits de l'utilisateur et ne pourra acceder que les choses auquel l'utilisateur peut acceder.
Ce que tu fais c'est empecher un user d'utiliser des fonctions deja ecrites qui de toute facon ne pourraient pas acceder a autre chose que ce que l'utilisateur a droit de toute facon.
J'ai l'impression que ce que tu fais est equivalent a :
Tu as une lib qui permet de lire des donnees du fichier de passwords, qui lui est limite en lecture a Administrator.
Tu essayes d'empecher les utilisateurs d'utiliser cette lib, alors que c'est totalement inutile, la lib tourne avec les droits de l'utilisateur, elle ne pourra de toute facon pas lire le fichier, et de toute facon rien n'empeche les utilisateurs d'ecrire eux meme un equivalent de la lib.


Ben c'est là qu'il y a problème, déjà je veux un utilisateur nobody et pas trois ca me simplifie grandement la vie. Ensuite j'aimerais bien savoir comment ils peuvent avoir par défaut les droits qui m'interressent ? de plus si je me souviens bien tes utilisateurs appartiennent au groupe "system" qui a des droits complets sur a peu près tout.

Ben ces utilisateurs ont chacun des limitations qui leur sont particulieres, si aucun de ceux la ne te convient, rien ne t'interdit de creer le tien. Et ces utilisateurs(a part LocalSystem) ont des droits tres restreints, NetworkService a des droits tres limites sur la machine locale, LocalService a des droits tres limites sur les droits reseau.
cf. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dl(...) pour plus d'info

Pour ce qui est d'avoir des users sans le droit de se logger localement, et autres limitations:
administrative tools -> local security policy -> local policies -> user rights assignments
Tu peux interdire a un user de se logger en local, en tant que service,etc...

Finalement pour ce qui est du probleme de bind, tu as un filtre IP en standard sur Windows, c'est dans les local security policies aussi(administrative tools -> local security policy -> IP security policies on local computer), et tu peux filtrer comme tu en as envie, sur les type de protocole, les addresses IP, les ports, tout ca en combinaison et avec des regexp(pas depuis la GUI cependant).

Sinon, effectivement tu ne peux pas mapper une share sur une autre machine, et partager le drive sur lequel est mappee cette partition.