mboost-dp1
unknown
Lyder fedt. Når man som ny c programmør kommer til sproget, bliver man overrasket over hvor mange sikkerhedshuller der er over alt.
Man kan kun vide de er der, hvis man ved præcis hvordan den underliggende arkitektur virker, så det er utroligt svært at gøre noget ved.
Med sådan et dokument kan man være rimelig sikker på at hardwaren ikke gør noget underligt under fødderne på én.
Man kan kun vide de er der, hvis man ved præcis hvordan den underliggende arkitektur virker, så det er utroligt svært at gøre noget ved.
Med sådan et dokument kan man være rimelig sikker på at hardwaren ikke gør noget underligt under fødderne på én.
Men altså... en standard definerer syntaks og semantik for et sprog. Hvordan i alverden vil man beskrive buffer-overløb som en konstruktion, så længe man brugere pointere?
Kilden nævner ikke ISO/ANSI C 06' nogen steder, så man må gå ud fra der blot er tale om retningslinier.
Kilden nævner ikke ISO/ANSI C 06' nogen steder, så man må gå ud fra der blot er tale om retningslinier.
Her er et mere præcist link til mere info.
Det drejer sig bare om udvidelse af C run-times, og ikke en decideret ændring af sproget. (så vidt jeg kan se). F.eks. er der kommet en strcpy_s(), der i modsætning til den normale strcpy() modtager et "max length" argument.
AFAIK har de fleste compilere/CRTs allerede noget tilsvarende, men det er jo altid rart at få sådan noget standardiseret så man kan bruge det i praksis (hvis man ikke vil bindes til en enkelt platform).
Det drejer sig bare om udvidelse af C run-times, og ikke en decideret ændring af sproget. (så vidt jeg kan se). F.eks. er der kommet en strcpy_s(), der i modsætning til den normale strcpy() modtager et "max length" argument.
AFAIK har de fleste compilere/CRTs allerede noget tilsvarende, men det er jo altid rart at få sådan noget standardiseret så man kan bruge det i praksis (hvis man ikke vil bindes til en enkelt platform).
[Update:] jeg tager det i mig igen - det de anbefaler er en udvidelse af biblioteket, så der tilføjes nye funktioner der er sikret imod disse overflow bugs.
Mange af funktionerne vil hedde det samme men få post-fixet "_s" på. så qsort() bliver til qsort_s().
---- gammel tekst: -----
Som #3 nævner - det er en udvidelse.
Jeg havde også lidt svært ved at tro at de laver en ISO standard om brug af pointere - især at microsoft skulle komme med ind dér.
Det de taler om er en udvidelse med nye character-typer. Jeg gætter på de tænker på en character type der automatisk opryddes.
Mere information kan findes her:
http://www.open-std.org/jtc1/sc22/wg14/www/project...
Mange af funktionerne vil hedde det samme men få post-fixet "_s" på. så qsort() bliver til qsort_s().
---- gammel tekst: -----
Som #3 nævner - det er en udvidelse.
Jeg havde også lidt svært ved at tro at de laver en ISO standard om brug af pointere - især at microsoft skulle komme med ind dér.
Det de taler om er en udvidelse med nye character-typer. Jeg gætter på de tænker på en character type der automatisk opryddes.
Mere information kan findes her:
http://www.open-std.org/jtc1/sc22/wg14/www/project...
#1
Der er ikke sikkerheds huller i c - det er et sprog. At sproget giver muligheder for sikkerhedshuller / fejl i dine *programmer* er en anden side af sagen - det er et "low-level" sprog og giver dig derfor ikke de konstruktioner som "high-level" sprog som XX.net, Java, mm. tilbyder - der imod har du muligheden for at gøre tingene hurtigere og gøre ting som ganske simplet ikke er muligt i de "high-level" sprog ( f.eks. skrive drivere ). Så det er et valg, og hvis man for ofte falder i "hullerne" kunne det være man burde genoverveje sit valg af et sprog.
Når man som ny c programmør kommer til sproget, bliver man overrasket over hvor mange sikkerhedshuller der er over alt.
Der er ikke sikkerheds huller i c - det er et sprog. At sproget giver muligheder for sikkerhedshuller / fejl i dine *programmer* er en anden side af sagen - det er et "low-level" sprog og giver dig derfor ikke de konstruktioner som "high-level" sprog som XX.net, Java, mm. tilbyder - der imod har du muligheden for at gøre tingene hurtigere og gøre ting som ganske simplet ikke er muligt i de "high-level" sprog ( f.eks. skrive drivere ). Så det er et valg, og hvis man for ofte falder i "hullerne" kunne det være man burde genoverveje sit valg af et sprog.
Jeg er nu mere interesseret i en arkitektur ændring der gør at det ikke er muligt at skrive i kode segmentet efter programmet er startet.
På den måde ville man kunne forhindre at buffer overflow eller underrun ville kunne udnyttes til at udføre kode programmet ikke var beregnet til.
På den måde ville man kunne forhindre at buffer overflow eller underrun ville kunne udnyttes til at udføre kode programmet ikke var beregnet til.
#6
Det lyder rimeligt platformsspecifikt. Det du snakker om er det som AMD kalder for et NX-bit (athlon64 og fremefter), og intel kalder for noget som jeg ikke kan huske. Windoze (XP SP2 og fremefter) understøtter det på softwareniveau.
At have direkte support i C for at kunne sætte dette bit for et hukommelsesområde, virker måske meget smart... men sådan et bit er et urimeligt krav at stille til den underliggende platform. Man skal trodsalt kunne skrive C til alverdens hardware, og det er sikkert kun 1% der understøtter det.
Som det er nu styres det igennem API kald, og det synes jeg er fint nok.
Det lyder rimeligt platformsspecifikt. Det du snakker om er det som AMD kalder for et NX-bit (athlon64 og fremefter), og intel kalder for noget som jeg ikke kan huske. Windoze (XP SP2 og fremefter) understøtter det på softwareniveau.
At have direkte support i C for at kunne sætte dette bit for et hukommelsesområde, virker måske meget smart... men sådan et bit er et urimeligt krav at stille til den underliggende platform. Man skal trodsalt kunne skrive C til alverdens hardware, og det er sikkert kun 1% der understøtter det.
Som det er nu styres det igennem API kald, og det synes jeg er fint nok.
Gad vide om det bliver et punkt i MS get the fud kampagnen i den overgang der sandsynligvis bliver hvor MS programmer er kodet med xxx_s kaldene og kan kalde sig sikkert ift. ISO standard XYZ.
Haha - ikke ment som en troll,
men de burde da have rigelig erfaring med alle disse buffer overflows nu, set i lyset af alle deres huller.
men de burde da have rigelig erfaring med alle disse buffer overflows nu, set i lyset af alle deres huller.
MS's seneste C/C++ compiler indsætter allerede nu alle mulige integritetscheck for at beskytte mod buffer overløb. Som default ovenikøbet.
Jeg skrev vist lidt om det, da jeg ville bygge en mini-exe. Der er nogle options der explicit skal slåes fra for at man bliver fri af C-runtime'n.
Det ender vist med lidt livrem, seler og noget ekstra klister. ;o)
Jeg skrev vist lidt om det, da jeg ville bygge en mini-exe. Der er nogle options der explicit skal slåes fra for at man bliver fri af C-runtime'n.
Det ender vist med lidt livrem, seler og noget ekstra klister. ;o)
lol #9 er sq da ikke flamebait - er da ret relevant - vil da æde min hat på at MS vil bruge det og sige "se her, Longhorn og Office kom-her version 2000 mange er ISO et eller andet sikkerhedscertificeret og udviklet med ISO et eller andet sikkerhedscertificerede værktøjer, og det er Linux ikke - øvbøv!" bare i en "pænere" udgave (trods alt ikke altid for kønt når Hr. Ballmer basher andre eller praiser sine egne produkter, men de skal nok bruge noget submarine PR også).
Kan da højst være irrelevant, selvom jeg nu mener det er en relativt relevant spekulation ift. tråden.
Kan da højst være irrelevant, selvom jeg nu mener det er en relativt relevant spekulation ift. tråden.
#12 Kunne det ikke tænkes at MS, bare engang imellem, ikke nødvendigvis er en koncern med 60.000 programmør-lemminger uden interesse for kvalitet og samarbejde?
Steve Balmer og Bill Gates har ikke meget med produkterne at gøre. Jeg bryder mig ikke om nogen af dem, men Don Box og Anders Hejsberg kan sku nogle ting. Jeg kan da lige nævne at Document-Literal formatet til WebServices som Microsoft står bag, nu er standardiseret af WS-I og endelig er alle parter ved at kunne "snakke med hinanden".
Det er jo ligesom bare et faktum, at da seneste C standard i 99' blev vedtaget, havde ikke mange forudset den myriade af sikkerhedsproblemer som stammer fra dovne programmørers brug af stak og heap. Så kudus fra mig af for at vedligeholde det mest alsidige og benyttede sprog vi har!
Steve Balmer og Bill Gates har ikke meget med produkterne at gøre. Jeg bryder mig ikke om nogen af dem, men Don Box og Anders Hejsberg kan sku nogle ting. Jeg kan da lige nævne at Document-Literal formatet til WebServices som Microsoft står bag, nu er standardiseret af WS-I og endelig er alle parter ved at kunne "snakke med hinanden".
Det er jo ligesom bare et faktum, at da seneste C standard i 99' blev vedtaget, havde ikke mange forudset den myriade af sikkerhedsproblemer som stammer fra dovne programmørers brug af stak og heap. Så kudus fra mig af for at vedligeholde det mest alsidige og benyttede sprog vi har!
#13: Det er rigtigt - "problemet" er bare at MS som virksomhed ikke ligefrem er kendt som samaritanere - tværtimod. Det er meget sjældent de går ind i standardgrupper mm. de har en grund til det. Ikke at deres W3C medlemskab betød meget andet en lobbyisme for at få patenterede teknikker gjort til recommendations.
#14, til trods for dette er deres C++ compiler den der ligger tættest på standarden (gcc 4.0 er dog vist lige så god endelig).
Anyway, håber ikke de laver andet end en udvidelse til sproget med nogle 'kopier' af eksisterende funktioner som det blev nævnt.
Men C folkene plejer nu at være rimelig nøgterne med hvad de inkluderer i sproget. De ville jo f.eks. ikke have den skarnsunge til Bjarne S.'s kode med :P
Anyway, håber ikke de laver andet end en udvidelse til sproget med nogle 'kopier' af eksisterende funktioner som det blev nævnt.
Men C folkene plejer nu at være rimelig nøgterne med hvad de inkluderer i sproget. De ville jo f.eks. ikke have den skarnsunge til Bjarne S.'s kode med :P
Jeg kan ikke lige se, hvad en ny standard skulle gøre godt for. Den eksisterende C standard tillader allerede at en implementation laver range checks på runtime. Der er mange tilfælde, hvor et programs opførsel er udefineret i henhold til standarden. Det vil sige at implementationen må gøre hvad den vil inklusiv at afbryde programmet med en fejlmelding.
Grunden til, at eksisterende C implementationer ikke gør det er primært performance. Et check hver eneste gang, der bruges en pointer, koster. Det vil helt naturligt også øge hukommelsesforbruget da der sikkert skal mere avancerede datastrukturer til memory management, og måske skal pointerne selv også internt repræsenteres af en datastruktur.
[url=#4]#4[/url] scarlac
Grunden til, at eksisterende C implementationer ikke gør det er primært performance. Et check hver eneste gang, der bruges en pointer, koster. Det vil helt naturligt også øge hukommelsesforbruget da der sikkert skal mere avancerede datastrukturer til memory management, og måske skal pointerne selv også internt repræsenteres af en datastruktur.
[url=#4]#4[/url] scarlac
Mange af funktionerne vil hedde det samme men få post-fixet "_s" på. så qsort() bliver til qsort_s().Nu har qsort jo aldrig været en af de funktioner, der var sårbar overfor bufferoverløb. Så hvad i alverden skulle ændres i en ny udgave? Man har jo altid skullet fortælle qsort, hvor mange elementer, der var i arrayet.
Nu har qsort jo aldrig været en af de funktioner, der var sårbar overfor bufferoverløb
Det er måske ikke den mest oplagte, men ikke destro mindre har scarlac ret:
void qsort_s(
void *base,
size_t num,
size_t width,
int (__cdecl *compare )(void *, const void *, const void *),
void * context
);
"qsort_s has the same behavior as qsort but has the context parameter and sets errno. By passing a context parameter, comparison functions can use an object pointer to access object functionality or other information not accessible through an element pointer. The addition of the context parameter makes qsort_smore secure because context can be used to avoid reentrancy bugs introduced by using static variables to make shared information available to the compare function".
[url=#19]#19[/url] mrmorris
Hvad i alverden er __cdecl? Prototypen giver syntaks fejl på min compiler. Jeg kan heller ikke se, hvad errno har at sige? Der er jo ikke nogen fejlsituationer qsort kan rapportere. Og bemærk lige, at den stadig ikke har nogen returværdi, så den kan ikke fortælle, om der har været en fejl.
Context paramteren kan da ganske sikkert være brugbar i mange situationer. Men de muligheder, den giver, eksisterer faktisk allerede i gcc. Man kan nemlig give en nested funktion som parameter til qsort, så ligger konteksten i trampolinen. Her er en triviel implementation af qsort_s vha. af den eksisterende qsort og en lokal funktion:
#include <stdlib.h>
void qsort_s(
void *base,
size_t num,
size_t width,
int ( *compare )(void *, const void *, const void *),
void * context
) {
int local_compare(const void *x, const void *y)
{
return compare(context,x,y);
}
qsort(base,num,width,local_compare);
}
qsort_s has the same behavior as qsort but has the context parameter and sets errno.Det er da sikkert en meget smart feature. Men det har bare intet med bufferoverløb at gøre.
Hvad i alverden er __cdecl? Prototypen giver syntaks fejl på min compiler. Jeg kan heller ikke se, hvad errno har at sige? Der er jo ikke nogen fejlsituationer qsort kan rapportere. Og bemærk lige, at den stadig ikke har nogen returværdi, så den kan ikke fortælle, om der har været en fejl.
Context paramteren kan da ganske sikkert være brugbar i mange situationer. Men de muligheder, den giver, eksisterer faktisk allerede i gcc. Man kan nemlig give en nested funktion som parameter til qsort, så ligger konteksten i trampolinen. Her er en triviel implementation af qsort_s vha. af den eksisterende qsort og en lokal funktion:
#include <stdlib.h>
void qsort_s(
void *base,
size_t num,
size_t width,
int ( *compare )(void *, const void *, const void *),
void * context
) {
int local_compare(const void *x, const void *y)
{
return compare(context,x,y);
}
qsort(base,num,width,local_compare);
}
#20
Specificerer calling convention for funktionen (om argumenterne skal på stakken forfra eller bagfra, hvor returværdien skal gemmes, om cpu-registrerne skal bruges osv). __cdecl er standard for C.
Spøjst.
Måske er det det den bruge errno til? :)
At en funktion absolut altid skal returnere dens fejlstatus igennem dens returværdi er en plage som M$ har gjort alt for at udbrede med deres daaarjlige Win32 API. Der findes sq smartere måder at gøre det på, IMO.
Smag og behag... Ligesom med nestede funktioner. Og så giver ting der ikke er bredt supported af de fleste compilere mig myrekryb.
Hvad i alverden er __cdecl?
Specificerer calling convention for funktionen (om argumenterne skal på stakken forfra eller bagfra, hvor returværdien skal gemmes, om cpu-registrerne skal bruges osv). __cdecl er standard for C.
Prototypen giver syntaks fejl på min compiler.
Spøjst.
Jeg kan heller ikke se, hvad errno har at sige? Der er jo ikke nogen fejlsituationer qsort kan rapportere. Og bemærk lige, at den stadig ikke har nogen returværdi, så den kan ikke fortælle, om der har været en fejl.
Måske er det det den bruge errno til? :)
At en funktion absolut altid skal returnere dens fejlstatus igennem dens returværdi er en plage som M$ har gjort alt for at udbrede med deres daaarjlige Win32 API. Der findes sq smartere måder at gøre det på, IMO.
Smag og behag... Ligesom med nestede funktioner. Og så giver ting der ikke er bredt supported af de fleste compilere mig myrekryb.
[url=#23]#23[/url] neckelmann
I øvrigt er diskussionen omkring fejlkoder irrelevant for qsort eftersom der ikke er nogen fejl den kan checke for.
Nu kan man selvfølgelig ikke overholde C standarden uden at have en errno, men der er ikke noget krav om, at den skal implementeres af kernen. Så faktisk er errno noget, som den libc, man har ovenpå kernen, tager sig af.
En global errno variabel er er problem fordi det ikke virker i multitrådede programmer. Problemet kan dog stort set løses med en preprocessor makro. Men allerhelst skulle errno erstattes med noget bedre.
Egentlig lyder det jo dybt tåbeligt at introducere en ny qsort med det formål at overflødiggøre nogle globale variable, hvis man samtidigt gør sig afhængig af en anden global variabel. Indtil jeg ser dokumentation for noget andet vil jeg stole på, at den ikke gør brug af errno.
Måske er det det den bruge errno til?Nej, du kan ikke bruge errno til at fortælle om der er sket en fejl. Men når der sker en fejl kan man bruge errno til at fortælle hvilken fejl, der er tale om. Du kan have en situation, hvor funktionen a kalder funktionen b, hvis b fejler sætter den errno, men a kan stadig godt returnere med success, og errno vil være blevet sat.
I øvrigt er diskussionen omkring fejlkoder irrelevant for qsort eftersom der ikke er nogen fejl den kan checke for.
At en funktion absolut altid skal returnere dens fejlstatus igennem dens returværdi er en plage som M$ har gjort alt for at udbrede med deres daaarjlige Win32 API.Jeg kender ikke M$ api, så jeg vil ikke udtale mig om hvorvidt fejlnumre håndteres fornuftigt. Men jeg kan da informere dig om, at Linux lægger fejlnummeret i returværdien. Der findes faktisk slet ingen errno i Linux.
Nu kan man selvfølgelig ikke overholde C standarden uden at have en errno, men der er ikke noget krav om, at den skal implementeres af kernen. Så faktisk er errno noget, som den libc, man har ovenpå kernen, tager sig af.
En global errno variabel er er problem fordi det ikke virker i multitrådede programmer. Problemet kan dog stort set løses med en preprocessor makro. Men allerhelst skulle errno erstattes med noget bedre.
Egentlig lyder det jo dybt tåbeligt at introducere en ny qsort med det formål at overflødiggøre nogle globale variable, hvis man samtidigt gør sig afhængig af en anden global variabel. Indtil jeg ser dokumentation for noget andet vil jeg stole på, at den ikke gør brug af errno.
#25
Med hensyn til om qsort umiddelbart ikke har noget at bruge errno til, så har du da uendeligt meget ret.
Det virker en smule underligt.
Jaja, at bruge en global variabel som errno til at tage sig af fejlstatus i en kernel, ville nok ikke være specielt intelligent.
Okay, nu er det også fordi jeg inde i mit lille hoved blander tingene lidt sammen med C++, hvor exceptions er mere bygget ind i sproget. I C står valget mere noget longjmp()-agtigt noget og så returværdier; hvad man så synes bedst om er vel op til en selv. Jeg ved godt at i hvert fald nogle C compilere tillader brug af exceptions, men det er vist ikke bredt nok understøttet til at det er et seriøst alternativ.
Men okay, den primære grund til at bruge C frem for C++ er vel (IMO) at man har mere styr på hvad der egentligt er der foregår - og hvis man gerne vil have det gyldne overblik over sit programflow, så er fejlhåndtering via returværdier sikkert det snedigste.
Det jeg prøver at skrive er vist at jeg er enig. :)
Snork.
Med hensyn til om qsort umiddelbart ikke har noget at bruge errno til, så har du da uendeligt meget ret.
Det virker en smule underligt.
Jaja, at bruge en global variabel som errno til at tage sig af fejlstatus i en kernel, ville nok ikke være specielt intelligent.
Okay, nu er det også fordi jeg inde i mit lille hoved blander tingene lidt sammen med C++, hvor exceptions er mere bygget ind i sproget. I C står valget mere noget longjmp()-agtigt noget og så returværdier; hvad man så synes bedst om er vel op til en selv. Jeg ved godt at i hvert fald nogle C compilere tillader brug af exceptions, men det er vist ikke bredt nok understøttet til at det er et seriøst alternativ.
Men okay, den primære grund til at bruge C frem for C++ er vel (IMO) at man har mere styr på hvad der egentligt er der foregår - og hvis man gerne vil have det gyldne overblik over sit programflow, så er fejlhåndtering via returværdier sikkert det snedigste.
Det jeg prøver at skrive er vist at jeg er enig. :)
Snork.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund