# Sicherheitsbewusssein, buffer overflows, etc, etc...

## ruth

hi,

heute mal ein no comment:

```

Zitat von rootshell

hi stefan,

ich habe gerade dein tool lxdvd entdeckt...

sehr schön, da ich mir nächsten monat endlich einen dvd brenner kaufen will (werde!!!) *lach*

hab's deswegen noch nicht ausprobiert, nur mal kurz im code gelesen; dabei ist mir auf die schnelle eines aufgefallen:

Code:

void check_program (char * szProgram, long lSprache)

{

  struct stat tmpStat;

  char filename[255];

  long bGefunden = 0;

  printf ("Test %s", szProgram);

  // Wenn kein Pfad gesetzt, dann im gesamten Pfad suchen

  if (!strstr (szProgram, "/"))

  {

    char szPfad[4096];

    int i;

    char szVerzeichnis[1024];

    strcpy (szPfad, getenv ("PATH"));

    strcpy (szVerzeichnis, "");

    for (i=0; i<strlen(szPfad); i++)

    {

      if (szPfad[i] == ':')

...

recht gefährlich, scheint mir...

du definierst szPath als [4096];

was passiert, wenn mein PATH > 4096 ist?

crash - boom - bang....

buffer overflow, klassischer natur... ;-)

mach doch bitte n' strncopy oder sowas draus... ;-)

ansonsten - top !!!

gruss

rootshell 

```

ANTWORT

```

Wer hat denn schon einen Pfad mit mehr als 4096 Zeichen? Das wird im ganzen Leben nicht krachen. Bei der Pfadlänge würde jeder Programmstart 10 min dauern.

...

Vielleicht mal in einem nächsten Release, aber derzeit sehe ich da keinen Änderungsbedarf. 

```

noch fragen, kienzle???

langsam sollte man doch halbwegs sicher programmieren - auch und gerade unter linux...

wenn dann ein autor auch noch _so_ reagiert...

dann mach ich das halt publik...  :Wink: 

viel spass damit....

gruss

rootshell

----------

## hoschi

ich kann zwar nur ein "hallo welt" in c++, aber wenn ich programmieren würde dann sicher/dauerhaft/flexibel

alles andere wäre doch "gefrickel"  :Very Happy: 

----------

## Aproxx

Was ist daran so schwer einfach ein "string" oder einen Char Pointer (C) zu verwenden? Warum alles statisch?

----------

## ruth

hi,

naja, statisch kann man das schon machen, wenn man will...

jedem das seine halt...  :Wink: 

mach ich ja auch - wie viele...

aber wenn, dann muss man halt aufpassen, dass man nicht über das ende des strings wegschreibt, sonst krachts halt... (wie hier....)

und sicherlich hat niemand einen PATH > 4096, das wird ja auch nur dann interessant, wenn jemand gezielt anfängt mit solchen werten zu arbeiten, d.h. gezielt einen exploit zu versuchen....

also wenigstens strncpy() mit NULL terminierung, dann wäre ich ja zufrieden, aber so????

und eine solch bornierte reaktion des authors?

naja, im übrigen schaut der rest des codes auch nicht viel besser aus...

btw. ist das teil (maskiert) (zum glück  :Wink:  ) im portage tree zu finden...

in letzter zeit wurde doch wirklich genug wind um buffer overflows, exploits und ähnliche sachen gemacht.

langsam müsste doch selbst der letzte kapieren, woher der wind weht...

oder lieg ich da total falsch?

ums mal so zu sagen:

ich mach auch bestimmt mal fehler, ein anderer findet ihn, sagt mir wo er ist, dann wird er halt gefixt...

aber sowas ist einfach nicht in ordnung (SIC!!)

gruss

rootshell

----------

## ian!

Genau. Augen offen halten, Bugs reporten. - Weiter so!  :Very Happy: 

----------

## chrib

Alternativ fixt man das selber und schickt dem Auto den entsprechenden Patch mit Erklärung zu.

Gruß

Christian

----------

## toskala

lieber rootshell, nun stell dich doch bitte mal nicht so an, bugs werden doch nur von bösen menschen ausgenutzt und wer ist denn schon so böse  :Wink: ?

*gacker* wenns bekannt genug is schicks an bugtraq  :Wink: 

----------

## mikkk

Das ist ja grauselig  :Shocked: !

So einen Buffer Overflow findet man ja schon als "Klassiker" in jedem Anfängerbuch über C/C++. Dazu kommt noch, dass in der manpage zu strcpy() ausdrücklich davor gewarnt wird. Hier mal ein Auszug aus dem Abschnitt "Bugs":

 *Quote:*   

> 
> 
>        If the destination string of a strcpy() is not large enough  (that  is,
> 
>        if  the programmer was stupid/lazy, and failed to check the size before
> ...

 

An Pisa & Co. ist wohl mehr dran als ich dachte...

mikkk

----------

## ruth

hi,

mensch, das ist ja die reinste spielwiese... *gg*

```

# export HOME=`perl -e 'printf "A" x 9500'` && ./lxdvdrip

Segmentation fault

#

```

da liest sich das hier doch gleich viel besser:

 *Quote:*   

> 
> 
> Wer hat denn schon einen Pfad mit mehr als 4096 Zeichen? Das wird im ganzen Leben nicht krachen. Bei der Pfadlänge würde jeder Programmstart 10 min dauern.
> 
> ...
> ...

 

und noch einiges mehr....

das oben sollte allerdings schon als proof of concept durchgehen...

und ob man den puffer mit AAA's überschreibt oder mit etwas lustigeren dingen.... *grins* ich schweife ab...  :Wink: 

gruss

rootshell

----------

## kavau

Ich verstehe nicht, warum die Leute für sowas nicht einfach die STL benutzen... Ja, schon, man hat ein bisserl Overhead, aber nix tragisches. Und wenn man std::string anstelle von char[] verwendet, muss man sich wegen Buffer Overflows zumindest keine Sorgen mehr machen. Ausserdem ist std::string viel bequemer als das ganze strcpy() Krams, sobald man sich mal an die STL gewöhnt hat.

Leute, die solchen Code schreiben, sollten von der Gentoo-Gemeinschaft exkommuniziert werden...   :Smile: 

----------

## ruth

hi,

is das nich nur für c++ ???

das is ja ein reines c programm...

ansich würde ja ein strncpy() mit sizeof() dafür reichen, dann noch ein \0 dranhängen und fertig....

ist also nicht wirklich aufwendig.

allerdings hab ich bei der durchsicht noch so einiges mehr gefunden...  :Wink: 

naja, solange man's nicht als suid root installiert...

aber immerhin kann man's dazu benutzen, eine initiale remoteshell zu kriegen...

von da dann noch ne lokale privilegieneskalation und...

your box has been r00ted !!!!

hmm, falls das ein dev liest:

könnte man das teil bitte (security)hardmasken?

danke !!!

gruss

rootshell

----------

## pablo_supertux

 *kavau wrote:*   

> Ich verstehe nicht, warum die Leute für sowas nicht einfach die STL benutzen... Ja, schon, man hat ein bisserl Overhead, aber nix tragisches. Und wenn man std::string anstelle von char[] verwendet, muss man sich wegen Buffer Overflows zumindest keine Sorgen mehr machen. Ausserdem ist std::string viel bequemer als das ganze strcpy() Krams, sobald man sich mal an die STL gewöhnt hat.
> 
> Leute, die solchen Code schreiben, sollten von der Gentoo-Gemeinschaft exkommuniziert werden...  

 

Vielleicht weil STL C++ ist und der Kernel in C geschrieben ist? (und auch das, was rootsehll hat). Oder willst du alles in C++ umschreiben, nur um die STL zu benutzen? Ich denke nur daran, wenn KDE 60 Stunden zum Kompilieren in Anspruch nimmt, wie lang werde ich dann für das bootstrapen oder emerge rsync warten? Eine Woche? Nein danke, ich bleibe lieber bei meinem buffer overflow.

@rootshell: Ich finde, dass du übereagierst. So dramatisch finde ich nicht, und Pfade > 4096 gibt es nun wirklich nicht, hab zumindest nie gesehen.

----------

## ruth

hi,

*prust*

@pablo:

oh mann, schuster bleib bei deinen leisten...

---rootshell schrieb mist hier ---, sorry

nochmal

```

# export HOME=`perl -e 'printf "A" x 9500'` && ./lxdvdrip

Segmentation fault

# 

```

...und schon ist HOME > 4096

wäre nett, wenn's nur qualifizierte postings gäbe

meinst du das ernst, was du schreibst???

im übrigen habe ich grade einen exploit fertiggestellt, der eine remote shell auf port XXXX über besagten fehler öffnet...  :Wink: 

(*gg* läuft das noch unter p.o.c.??? *gg*)

gruss

rootshell

----------

## pablo_supertux

 *rootshell wrote:*   

> 
> 
> du bist peinlich...
> 
> 

 

danke, schönes Kompliment, ich fühl mich geehrt

Ich mein nur folgendes: Ich hab 2 Mal im Leben KDE (alles auf C++ geschrieben) kompiliert und ich hab mind. 60 Stunden geopfert.

Gut, die STL hat schöne Sachen, stimmt, das mit std::string ist wirklich schön, weil man sich nicht mehr um die Länge des Buffer kümmern muss. Aber wenn der ganze Kernel und fast jede Bibliothek in C++ umgeschrieben werden müsste. damit wir davon profitieren, wie lange würde man brauchen, um Gentoo zu installieren? Mit meiner Maschine eine gute Woche, oder? 

Nein, rootshell, ich will auch keine Buffer overflows und ich will auch keine exploits, ich frage mich nur, ob ich auch bereit bin, den Linux kernel & tools zu kompilieren, wenn alles in C++ geschrieben wäre? Mit den von dir erzeugten exploit hast Recht, das ist schrecklich, da schließe ich toskala an: "bugs werden doch nur von bösen menschen ausgenutzt und wer ist denn schon so böse?" (wenn das wirklich wahr wäre)

----------

## ruth

hi,

--- rootshell schrieb nochmal mist hier ---

was hat denn das ganze mit compilerzeit zu tun???   :Shocked: 

----------

## kavau

 *pablo_supertux wrote:*   

> Vielleicht weil STL C++ ist und der Kernel in C geschrieben ist? (und auch das, was rootsehll hat). Oder willst du alles in C++ umschreiben, nur um die STL zu benutzen? Ich denke nur daran, wenn KDE 60 Stunden zum Kompilieren in Anspruch nimmt, wie lang werde ich dann für das bootstrapen oder emerge rsync warten? Eine Woche? Nein danke, ich bleibe lieber bei meinem buffer overflow.

 

Der code ist aber für ein DVD-ripping-tool und nicht für den Kernel. C code auf C++ zu portieren ist kein großer Aufwand, weil C++ zu 98% backwardskompatibel ist. Längere Kompilierzeiten nehme ich für Sicherheit und verbessertes Design gerne in Kauf. Aber wenn Du gerne in der Vergangenheit lebst, bitte sehr, das ist Deine Entscheidung.

----------

## kavau

 *pablo_supertux wrote:*   

> Ich mein nur folgendes: Ich hab 2 Mal im Leben KDE (alles auf C++ geschrieben) kompiliert und ich hab mind. 60 Stunden geopfert.

 

Echt? Also, ich lass das immer meinen Computer erledigen. Von meiner eigenen Zeit gehen dann nur etwa fünf Sekunden drauf. Aber wenn Du den ganzen Code von Hand kompiliert hast, dann sind 60 Stunden schon eine beachtliche Leistung. Alle Achtung!

Für den Fall, daß ich Dich falsch verstanden habe, hier noch'n heißer Tip: Der Compiler tut seine Arbeit auch wenn man nich' vorm Bildschirm klebt und den vorbeirollenden Zeilen zuschaut...

----------

## pablo_supertux

 *kavau wrote:*   

>  *pablo_supertux wrote:*   Ich mein nur folgendes: Ich hab 2 Mal im Leben KDE (alles auf C++ geschrieben) kompiliert und ich hab mind. 60 Stunden geopfert. 
> 
> Echt? Also, ich lass das immer meinen Computer erledigen. Von meiner eigenen Zeit gehen dann nur etwa fünf Sekunden drauf. Aber wenn Du den ganzen Code von Hand kompiliert hast, dann sind 60 Stunden schon eine beachtliche Leistung. Alle Achtung!
> 
> Für den Fall, daß ich Dich falsch verstanden habe, hier noch'n heißer Tip: Der Compiler tut seine Arbeit auch wenn man nich' vorm Bildschirm klebt und den vorbeirollenden Zeilen zuschaut...

 

Hallo, ihr braucht mich nicht fertig zu machen, ich hab schon kappiert, dass ich da einen Blödsinn gepostst hab und dass Compile Zeit wirklich nix mit dem Thema zu tun hatte; irren ist menschlich; und jetzt wo ich meine Post wieder lese, sehe ich, dass ich nicht wirklich mein Hirn benutzt hab, als ich das gepostet hab, aber das gibt EUCH nicht das Recht, mich so zu behandeln, ein bisschen mehr Respekt für alle, manche vergessen schnell, dass Menschen hinter den Bildschirmen sitzen.

Und blöd bin ich auch nicht, glaubst du ich blieb da die 60 Stunden vor dem Computer sitzen, bis alles fertig war? Natürlich nicht. In der Nacht hab ich auch meinen PC ausgeschaltet (sonst kann man mit dem Lärm nicht schlafen) und am Tag weiter gemacht. Also lass das bitte.

----------

## EOF

@rootshell

Kann es nicht sein, dass du den autor von lxdvd beleidigt hast? Hätte es nicht gereicht einen exploit zu schicken? Das wäre eine möglichkeit gewesen dein umfassendes wissen zu teilen. Nun darf sich der autor über den öffentlichen pranger freuen und verliert evtl. die lust am programmieren.

@alle

Kompiliert C kompatibler C++ code mit g++ deutlich langsamer als mit gcc? 

Dafür möchte ich gerne einen link.

Da C++ zur kompilezeit turing vollständig ist (stichwort meta templates) kann ich leicht C++ (nicht C) programme schreiben, die beliebig lange kompilieren ...

----------

## amne

Ganz ruhig, Leute. Alle mal tief ein- und ausatmen, Raucher dürfen auch rauchen. Dann gepflegt weiterposten.

----------

## ian!

 *rootshell wrote:*   

> allerdings hab ich bei der durchsicht noch so einiges mehr gefunden... 
> 
> naja, solange man's nicht als suid root installiert...
> 
> aber immerhin kann man's dazu benutzen, eine initiale remoteshell zu kriegen...
> ...

 

Da du die Stellen im Code besser kennst, würde ich dich bitten das auf bugs.gentoo.org oder im IRC in #gentoo-security zu reporten. Danke!

----------

## ruth

hi,

 *Quote:*   

> 
> 
> hi stefan,
> 
> ich habe gerade dein tool lxdvd entdeckt...
> ...

 

 *EOF wrote:*   

> 
> 
> Kann es nicht sein, dass du den autor von lxdvd beleidigt hast?
> 
> 

 

sieht das da oben für dich wie eine beleidigung aus???  :Shocked: 

 *Quote:*   

> 
> 
> Hätte es nicht gereicht einen exploit zu schicken?
> 
> Das wäre eine möglichkeit gewesen dein umfassendes wissen zu teilen.
> ...

 

nochmal:

das, was ganz oben als zitat steht, das hab ich dem autor geschickt...

also das da:

hi stefan,

ich habe gerade dein tool lxdvd entdeckt...

[...]

@EOF:

wenn du das als beleidigung auffassst, dann leben wir beide wahrscheinlich in zwei verschiedenen welten.

die reaktion des autors war folgende:

 *autor wrote:*   

> 
> 
> Wer hat denn schon einen Pfad mit mehr als 4096 Zeichen? Das wird im ganzen Leben nicht krachen. Bei der Pfadlänge würde jeder Programmstart 10 min dauern.
> 
> ...
> ...

 

tja, auf diese antwort hab ich's dann halt veröffentlicht - ende...

und bzgl exploit:

sobald du einen PATH hast, der lang genug ist krachts...

sollte als POC reichen:

```

# export HOME=`perl -e 'printf "A" x 9500'` && ./lxdvdrip

Segmentation fault

# 

```

auch das habe ich schon geschrieben.... 

 :Rolling Eyes: 

fazit:

der autor sieht keine notwendigkeit, den code zu ändern.

daher ist auch ein bugreport nutz-/sinnlos.

und genau deswegen hab ich das publik gemacht;

nicht, weil er einen fehler gemacht hat.

hallo, ich mach auch fehler, jeder von uns macht fehler...

der grund war die reaktion, dass er eben _nicht_ willens ist, diese fehler zu beheben.

und für ein

<<<strcpy()

>>>strncpy()

brauch ich wirklich keinen patch schicken...

gruss

----------

## marc

rootshell schrieb: *Quote:*   

> fazit: 
> 
> der autor sieht keine notwendigkeit, den code zu ändern. 
> 
> daher ist auch ein bugreport nutz-/sinnlos. 
> ...

 

aber genau deswegen solltest du erst recht einen bugreport schreiben. fehler die offensichtlich sind sollen (müssen) veröffentlicht werden. wir nutzen os und können keinen vorteil daraus ziehen weil einer keine lust hat etwas zu ändern oder welcher grund auch immer .......

bugreport: bla bla ..... so könnte ein exploit aussehen bla bla .....

wenn der autor dann trotzig wird und sagt ich programmiere nix mehr dann lass ihn doch. ist doch unsinnig die ganze diskussion. vielleicht schreibt jemand anders einen patch und schickt ihm den author. von rootshell lässt der sich vielleicht halt nix sagen.  :Smile: 

nix für ungut

----------

## ruth

hi,

*schmunzel*

 *marc wrote:*   

> von rootshell lässt der sich vielleicht halt nix sagen. 
> 
> nix für ungut

 

... *grins* ja, das wirds sein,. vermutlich...  :Wink: 

gruss

flo

----------

## LockeAverame

najo bei dem code würde ich das programm sicher nicht nutzen wollen. und ja g++ compiliert länger bei c++ kompatiblen c code, liegt am anderen frontend. ich würde auch eher seltener statische arrays nehmen da sie doch recht viel cache speicher fressen ohne großen nutzen, aber egal, bei dem code da oben macht das dann glaube auch nix mehr aus. die richtig nervigen buffer overflows sind meist die, die gcc selber produziert ^^.

achja STL is ne nette sache, aber wer gut programmiert schreibt performanter in c und hat ebenfalls nicht das problem mit solchen buffer overflows. die STL is selbst ein ziemlicher hack (ein schelm wer die header files liest).

cu

----------

## EOF

@rootshell

Wen es um sachliche dinge geht, sollte man sein "weltbild" anpassen und emotionsloser gestalten. Wie soll der gegenüber wissen wie du dich im wirklichen leben verhällst, wenn er nur text zu lesen bekommt.

Beispielsweise könnte er deinen text folgendermassen deuten:

Findest du blutiger anfänger deinen lxdvd code auch so lustig wie ich? Besser du schreibst wieder rezepte für die dorf-currywurstbude und gefährdest nicht die staatssicherheit. Mir kommt der tarball hoch, wenn ich dieses digitale klopapier sehe.

Ich, dein oberinspektor rootshell von der gentooer code polizei sage dir ...

*bow*

Gereicht hätte:

Mir ist aufgefallen ....

Ein start von lxdvd mit ... kommt einem "rm -rf" als root gleich, denn ...

Wenn er sich dann noch quer stellt alarm schlagen  :Smile: .

Gruss

----------

## EOF

 *LockeAverame wrote:*   

> 
> 
> [...] achja STL is ne nette sache, aber wer gut programmiert schreibt performanter in c und hat ebenfalls nicht das problem mit solchen buffer overflows. die STL is selbst ein ziemlicher hack (ein schelm wer die header files liest).
> 
> cu

 

Kann es sein, dass du den stl code nicht verstehst. Zeige mit mal ein beispiel für uneleganten stl code.

[...] performanter [...]

Was willst du uns mit diesem satz sagen ?

----------

## ralph

Also wirklich, ich begreiffe die Diskussion hier nicht mehr. Ich habe mir jetzt nochmal die mail von rootshell durchgelesen und es ist mir völlig schleierhaft, wie sich jemand von dieser auf den Schlips getreten fühlen könnte, ausser und ich fürchte das ist hier der Fall, seine Kritikfähigkeit tendiert gegen Null. In diesm Falle liegt das Fehlverhalten einzig und allein beim Autor des Codes, bei niemandem sonst.

P.S.: Wo ich gerade schonmal bei Stilkritik bin, die Art wie in diesem Thread mit manchen Leuten umgegangen wurde ist schlicht zum kotzen.

----------

## _hephaistos_

ich find das auch nicht schlimm, weil das ist ja auch Sinn von OpenSource. in einem NON OS Produkt, fällt sowas nicht auf und krach-bumm alles is hin (gibt da eine lustige Geschichte von Jeremy Allison und Samba, wo auf einmal sämtliche WinClients angefangen haben sich zu rebooten usw)  :Smile: 

aber bei OpenSource kann man eben darüber diskutieren und seine Meinungen wohl kund tun - und genau das ist auch der Vorteil von OpenSource (siehe the Cathedral and the Bazaar). Wer so etwas nicht aushalten kann, sollte besser kein OpenSource programmieren.

ciao

----------

## LockeAverame

zum thema performanter, STL checked jede änderung des strings, das kostet zeit, schau dir einfach den asm output an. und zum thema header:

schau zB mal in stl_stack.h, kleiner ausschnitt:

template <typename _Tp, typename _Sequence>

    class stack

  {

    // concept requirements

    typedef typename _Sequence::value_type _Sequence_value_type;

    __glibcpp_class_requires(_Tp, _SGIAssignableConcept)

    __glibcpp_class_requires(_Sequence, _BackInsertionSequenceConcept)

    __glibcpp_class_requires2(_Tp, _Sequence_value_type, _SameTypeConcept)

    template <typename _Tp1, typename _Seq1>

    friend bool operator== (const stack<_Tp1, _Seq1>&,

                            const stack<_Tp1, _Seq1>&);

    template <typename _Tp1, typename _Seq1>

    friend bool operator< (const stack<_Tp1, _Seq1>&,

                           const stack<_Tp1, _Seq1>&);

  public:

    typedef typename _Sequence::value_type                value_type;

    typedef typename _Sequence::reference                 reference;

    typedef typename _Sequence::const_reference           const_reference;

typedef typename _Sequence::size_type                 size_type;

    typedef          _Sequence                            container_type;

  protected:

    //  See queue::c for notes on this name.

    _Sequence c;

  public:

    // XXX removed old def ctor, added def arg to this one to match 14882

    /**

     *  @brief  Default constructor creates no elements.

    */

    explicit

    stack(const _Sequence& __c = _Sequence())

    : c(__c) {}

ich würd sagen einige hässliche workarounds.

cu

----------

## ruth

hi,

ich befürchte, das mit dem stil leuten gegenüber betrifft mich...

deshalb:

sorry, pablo....  :Wink: 

entschuldigung...

hmm, man sollte nach einer dreiviertel flasche wein (gestern) einfach nichts mehr schreiben dürfen....  :Wink: 

hatte dir gegenüber überreagiert, kommt nicht wieder vor...

gruss

flo

ach:

@EOF:

lies mal ein bischen bugtraq mit - da sagen sich die coder sehr genau und explizit, was sie von einem code halten....

bedeutet:

wenn ich im letzten satz schreibe

ansonsten - top !!!

dann meine ich das auch so;

das tool gefällt mir, weil es eben meine bedürfnisse erfüllt.

so und nicht anders ist das gemeint...  :Wink: 

und es gibt eben einige sachen, die mir nicht gefallen;

das hat aber leider nichts mehr mit stil zu tun sondern, so leid es mir tut, mit ignoranz:

```

BUGS

       If the destination string of a strcpy() is not large enough  (that  is,

       if  the programmer was stupid/lazy, and failed to check the size before

       copying) then anything might happen.  Overflowing fixed length  strings

       is a favourite cracker technique.

```

sogar man strcpy spricht hier sehr explicit lyrics....  :Wink: 

----------

## LockeAverame

das nicht nutzen von STL bezog sich auf reinen c code, in c++ würde ich durchaus STL nutzen, nur halt die aussagen, das man doch alles in c++ schreiben möge, halte ich für nonsense.

----------

## ruth

naja,

einigen wir uns darauf, dass strings und C problematisch ist...  :Wink: 

btw:

hat jemand erfahrung mit bstring?

zumindest die README liest sich super:

```

Motivation

----------

The standard C string library has serious problems:

    1) Its use of '\0' to denote the end of the string means knowing a 

       string's length is O(n) when it could be O(1).

    2) It imposes an interpretation for the character value '\0'.

    3) gets() always exposes the application to a buffer overflow.

    4) strtok() modifies the string its parsing and thus may not be usable in

       programs which are re-entrant or multithreaded.

    5) fgets has the unusual semantic of ignoring '\0's that occur before

       '\n's are consumed.

    6) There is no memory management, and actions performed such as strcpy,

       strcat and sprintf are common places for buffer overflows.

    7) Passing NULL to C library string functions causes an undefined NULL 

       pointer access.

    8) Parameter aliasing (overlapping, or self-referencing parameters) 

       within most C library functions has undefined behavior.

    9) Many C library string function calls take integer parameters with 

       restricted legal ranges.  Parameters passed outside these ranges are

       not typically detected and cause undefined behavior.

So the desire is to create an alternative string library that does not suffer

from the above problems and adds in the following functionality:

```

sowas wäre doch schön, oder?

gruss

flo

----------

## LockeAverame

das meiste kannste bereits mit eigenen ADTs realisieren zB:

struct string {

unsigned long int length = 0;

char *array; };

ein reference-counter der sich um die (de/re)allokierung kümmert tut sein übriges und kann recht schlank implementiert werden.

c ist halt mehr lowlevel, STL is natürlich in der Nutzung eleganter aber alles andere als performant. ürbigens wurde damals c mit gutem stringhandling im hinterkopf als hauptaufgabe entwickelt  :Smile: , naja die zeiten ändern sich ^^.

cu

----------

## pablo_supertux

Ich hab auch sehr lange gebraucht, bis ich mit den char*/char[] unter C umgehen konnte, und am Anfang hat es mich angekotzt, heute gefällen sie mir. Ich bin kein C++ Fan aber wo ich zugeben muss, ist dass C++ ein sehr großer Schritt voraus ist, wenn man die STL benutzt und vor allem, wenn man std::string benutzt.

Verhindern, dass die in Open Source Code C benutzt wird, ist wie verhindern, dass man ohne Wasser kocht. Aber vielleicht kann man so etwas ähnlcihes wie std::string in C auch implementieren. GTK ist C aber hat viele Konzepte der OOP und C++ integriert und so, und das mag ich an GTK. Vielleicht ist es die Stunde gekommen, C weiter zu entwickeln, so dass solche exploits nicht mehr möglich sind.

@rootshell: Welche README meinst du?

----------

## LockeAverame

naja c weiterentwickeln würde ich mir gut überlegen, du kannst alles was du in c++ hast auch in c implementieren, beide sind turing complete.

c hat natürlich nicht sonderlich viel komfort, ist dafür aber recht übersichtlich und eben sehr schnell und relativ leicht zu parsen.

wer will kann sich ja für bestimmte fälle libs anschaffen, aber ich würde sie nicht fest reinkloppen, da es für zB embedded systems sinnfreier overhead ist. java zB sagt mir in sachen anwendungsprogrammierung deutlich eher zu als c++ (ich hoffe mal das jetzt kein flamewar beginnt über sprachen/syntax/design). bufferoverflows sind auch nicht nur programmierfehler sondern auch architekturfehler insbesondere bei x86, was man eigentlich nur als krüppelarchitektur bezeichnen kann, naja egal, besser auch hier kein flamewar ^^.

----------

## mikkk

Auf C rumzuhacken bringt doch nix. Wenn man noch ein paar "Idiotensicherungen" einbaut, muss das die Sprache noch lange nicht sicherer machen. Entscheidend ist doch, dass der Programmierer über die nötigen Fähigkeiten verfügt und von allem den *Willen* besitzt, ordentliche Programme zu schreiben.

Und vor allem an letzterem scheint es ja hier zu mangeln. Mit so einer Einstellung kann das nichts werden, egal mit welcher Sprache.

mikkk

----------

## LockeAverame

du vergisst dabei, dass projekte in C mit der zeit sehr groß und komplex werden können und sich da schnell nichttriviale fehler einschleichen können, die bei C schnell auftreten können. ich sage nicht, dass die sprache schlecht ist (immerhin meine lieblingssprache), aber für manche fälle ist sie nicht unbedingt so gut geeignet. man kann es natürlich dennoch hinbekommen, dies verlangt dann aber mehr arbeit im code management und dokumentation. der vorteil in C ist eben das man nicht soviel highlevel balast hat, sondern sich diesen realisieren kann, wenn man ihn denn braucht.

----------

## kavau

 *LockeAverame wrote:*   

> die richtig nervigen buffer overflows sind meist die, die gcc selber produziert ^^.
> 
> achja STL is ne nette sache, aber wer gut programmiert schreibt performanter in c und hat ebenfalls nicht das problem mit solchen buffer overflows. die STL is selbst ein ziemlicher hack (ein schelm wer die header files liest).cu

 

 :Shocked:  Interessant. Ich hatte bisher einen recht ordentlichen Eindruck von der STL. Hast Du ein paar mehr informationen/links zu den Schwachstellen der STL und den gcc-generierten buffer overflows?

----------

## EOF

 *LockeAverame wrote:*   

> zum thema performanter, STL checked jede änderung des strings, das kostet zeit, schau dir einfach den asm output an. und zum thema header:
> 
> schau zB mal in stl_stack.h, kleiner ausschnitt:
> 
> [...]
> ...

 

Für was zum ... brauchst du denn unbedingt schnelle STL strings ? Weisst du was templates sind ? Warum hast du überhaupt geantwortet, wenn du kein C++ kannst ? 

http://www.sgi.com/tech/stl/stl_stack.h

----------

## EOF

 *LockeAverame wrote:*   

> naja c weiterentwickeln würde ich mir gut überlegen, du kannst alles was du in c++ hast auch in c implementieren, beide sind turing complete. [...]
> 
> 

 

Schreib folgendes programm mal in C. Es berechnet fibonacci zahlen zur kompilezeit und gibt sie als fehlermeldungen beim kompilieren aus. Viel spass  :Smile: .

```

// Class to create "output" at compile time (error message)

template<int f> struct D {};

// Class to iterate all values a1, a2, ... am

template<int fa, int fb, int i>

struct Fib_Print {

   Fib_Print<fb, fa+fb, i-1> a;

   void f() { a.f(); D<fa> d = 0;  }

};

template<int fa, int fb>

struct Fib_Print<fa, fb, 0> {

   void f() {}

};

void foo() {

   Fib_Print<0, 1, 10> a;      // a0 = 0, a1 = 1, m = 10

   a.f();

}

```

----------

## LockeAverame

wie kommste auf die idee, dass ich kein c++ kann? das beispiel bezog sich auf die nicht sonderlich glücklich gewählten bezeichner und einige glibc specials.

und fibonacci zahlen rekursiv zu bestimmen is doch nun lange nen alter hut und ineffizient. zumal der präprozessor garantiert langsamer argiert ^^.

----------

## pablo_supertux

@EOF: ich weiß, dass C++ sehr elegant sein kann, vor allem mit den templates. Aber ob man dein Beispiel im Leben wirklich braucht? Ich mein nur, was nutzt mir ein Programm, dass sich nicht kompilieren lässt? Ich glaube, dass sowas in C nicht möglich wäre, aber wenn das Programm nicht kompilierbar ist, wozu es schreiben? Naja, wennn man Spaß am Programmieren haben will, ist das ok. Aber um zu zeigen, dass C++ besser als C ist, finde ich, dass das kein besonders gutes Beispiel ist.

----------

## LockeAverame

es ist überhaupt kein beispiel für besser/schlechter. äpfel mit birnen zu vergleichen ist schon recht bescheiden.

----------

## Carlo

 :Arrow:  Bug 64628

@rootshell: Das nächste Mal stell den Bug Report bitte selber rein. Das geht a) schneller und b) bist Du als wertvolles Community-Mitglied dazu moralisch verpflichtet.  :Twisted Evil: 

----------

## Jtb

das ist mal wieder einer der Momente, wo ich mich freue kein C/C++ zu programmieren..

Es mag gut sein, dass "manche" Leute das Letzte aus ihrem Code rausholen wollen und auch das entsprechende Know-How haben dieses so zu tun, dass es sicher ist.. Vorteil: schnell aber sicher..

Mangelndes Sicherheitsbewußtsein ist aber leider heutzutage normal. So ist es verständlich, dass der Programmierer sagt, dass ihn das Problem nicht interessiert - er sieht das Problem nicht weil er lieber an den Programm arbeiten möchte UND nicht an der (sicherern) Umsetzung..

Das ganze sind imho Überreste aus den "Urzeiten" - bald wird es zwei Arten von Programmierern geben: Systemprogrammierer, die auf Geschwindigkeit aber auch Sicherheit achten und eine low-Level Sprache benutzen (und dazu zähle ich auch C/C++). Die andere Art bilden die reinen Anwendungsprogrammierer, die mit einer Sprache arbeiten, die eventl. nicht soviel im low-Level kann, dafür dem Programmierer aber viel Arbeit ab-/wegnehmen - Vorzugsweise über eine virtuelle Maschine (Java, dotNet usw).. Dort wird die einzige Art das Programme Programme ändern über saubere Reflection laufen.

btw: ich bin froh, dass es Buffer-Overflow-Schutz mittlerweile in Hardware gibt..

----------

## LockeAverame

dem kann ich nur zustimmen jtb. anwendungsentwicklung macht sich unter java einfach besser, man spart arbeit und die sicherheit des codes ist wesentlich höher, die statistische wahrscheinlichkeit dort kritische bugs reinzuhauen ist einfach geringer. von der performance her ist java sowieso alles andere als langsam solange man nicht stringhandling und gui in betracht zieht. und speicherschutzmechanismen in hardware haben nun seit langem endlich auch mal in die x86 welt einzug gehalten, wenigstens etwas in die richtige richtung ala powerpc.

----------

## mikkk

 *Quote:*   

> 
> 
> Das ganze sind imho Überreste aus den "Urzeiten" - bald wird es zwei Arten von Programmierern geben: Systemprogrammierer, die auf Geschwindigkeit aber auch Sicherheit achten und eine low-Level Sprache benutzen (und dazu zähle ich auch C/C++). Die andere Art bilden die reinen Anwendungsprogrammierer, die mit einer Sprache arbeiten, die eventl. nicht soviel im low-Level kann, dafür dem Programmierer aber viel Arbeit ab-/wegnehmen - Vorzugsweise über eine virtuelle Maschine (Java, dotNet usw).. Dort wird die einzige Art das Programme Programme ändern über saubere Reflection laufen.
> 
> 

 

Solche "Visionen" sind im Umlauf, seit es Programmiersprachen gibt. Diesen Spruch hättest Du auch in den 60er Jahren loslassen können, als gerade BASIC erfunden war.

Und Virtuelle Maschinen sind fast genauso alt (bekannt geworden sind sie vor allem in den 70er Jahren im Zusammenhang mit Pascal und Smalltalk).

Und genauso wenig wie damals wird man die heutigen Probleme beim Programmieren (die ja im wesentlichen gleich geblieben sind) damit lösen können. Gute Ausbildung, Praxiserfahrung und den Willen ordentlich zu programmieren kann man eben nicht durch elegante Konzepte ersetzen.

Dazu kommt noch, dass diese Kozepte extrem ineffizient sind. Und das ist für den Endnutzer häufig ausschlaggebend bei der Wahl von Software.

mikkk

----------

## Jtb

na ja, das Konzept der VM ist jedenfalls sehr verbreitet - sei es Java, dotNet oder Perl6..

btw: zähl mal die Basic-Entwickler  :Wink: 

und das musst du nicht auf Basic beschränken - php, perl, python usw..

----------

## ruth

hi,

@Carlo:

is ja gut... *gg*

wo wir grade dabei sind:

```

...

char szBefehl2[4096];

...

        strcpy (szBefehl, getenv ("HOME"));

        strcat (szBefehl, "/.lxdvdrip.conf");

        fConf=fopen(szBefehl, "r");

```

so in zeile 1052ff.

das gleiche mit $HOME;

auch getestet als exploitable...

mit patches wird man da nicht mehr weit kommen...

da müsste man sich schon die ~5200 Zeilen mal komplett geben...

was macht man denn in so einem fall??? *gg*

ach ja:

ich war gestern mal auf #gentoo-security,

leider haben da wohl grade alle geschlafen oder so;

jedenfalls war nichts los da...

deswegen hab ichs noch nicht reportet gehabt...  :Wink: 

gruss

rootshell

----------

## Carlo

 *rootshell wrote:*   

> 
> 
> ich war gestern mal auf #gentoo-security,
> 
> leider haben da wohl grade alle geschlafen oder so;

 

Dann versuch's lieber via #gentoo-bugs oder ping einen dev an, dann gibt's durchaus +v für #gentoo-dev. Sicherheitslücken sollten aber eh via Bugzilla nachvollziehbar sein.

 :Arrow:  Gentoo Linux Vulnerability Treatment Policy, 2. Vulnerability feed

----------

## EOF

 *pablo_supertux wrote:*   

> @EOF: ich weiß, dass C++ sehr elegant sein kann, vor allem mit den templates. Aber ob man dein Beispiel im Leben wirklich braucht? Ich mein nur, was nutzt mir ein Programm, dass sich nicht kompilieren lässt? Ich glaube, dass sowas in C nicht möglich wäre, aber wenn das Programm nicht kompilierbar ist, wozu es schreiben? Naja, wennn man Spaß am Programmieren haben will, ist das ok. Aber um zu zeigen, dass C++ besser als C ist, finde ich, dass das kein besonders gutes Beispiel ist.

 

Es ging nicht darum zu zeigen was "besser" ist. Es ging nur darum die von mir zitierte aussage von Locke zu relativieren. Jedenfalls hast du das code beispiel wenigstens verstanden. Welchen praktischen nutzen template meta programme haben sagt dir z.b. google mit:

http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html

----------

## kavau

 *Jtb wrote:*   

> Das ganze sind imho Überreste aus den "Urzeiten" - bald wird es zwei Arten von Programmierern geben: Systemprogrammierer, die auf Geschwindigkeit aber auch Sicherheit achten und eine low-Level Sprache benutzen (und dazu zähle ich auch C/C++). Die andere Art bilden die reinen Anwendungsprogrammierer, die mit einer Sprache arbeiten, die eventl. nicht soviel im low-Level kann, dafür dem Programmierer aber viel Arbeit ab-/wegnehmen - Vorzugsweise über eine virtuelle Maschine (Java, dotNet usw).. Dort wird die einzige Art das Programme Programme ändern über saubere Reflection laufen.

 

Da kann ich nur zustimmen. C und C++ stammen aus einer Zeit, in der performance eben noch ein kritischer Faktor war. Auf heutigen computern muss man Ausfuehrungsgeschwindigkeit eben nur noch an wichtigen Knotenpunkten in betracht ziehen, 95% des Codes laeuft eh schnell genug, egal in welcher Sprache und mit welchen tricks programmiert wurde.

Persoenlich programmiere ich heutzutage immer mehr in Python. Zugegeben, es ist deutlich langsamer als C, aber wenn man die richtigen Module benutzt, schnell genug fuer die meisten Anwendungen. Und weil die meisten Programmierfehler automatisch eine Exception ausloesen, anstatt undefinierte Resultate zu liefern, hat der Code eine wesentlich bessere Qualitaet. Noch vor einem Jahr habe ich fast ausschliesslich in C++ programmiert...

Was die Welt m.A. braeuchte, ist eine Art "C++ - C", d.h. eine schnelle, kompilierte Sprache, mit sicheren Klassen wie in der C++ STL, aber ohne die anachronistischen C-Elemente. Wahrscheinlich gibt es so eine Sprache bereits, aber das Problem ist halt immer, dass sie sich auch durchsetzen muss.

----------

## LockeAverame

naja relativ gut ist eiffel, nur leider kaum support und gute compiler bekommste dafür auch net, naja kann man nix machen. smarteiffel umgeht immerhin das meiste der probleme indem sie den code in C umsetzen lassen und man es dann mit gcc und co übersetzen kann, nicht unbedingt die beste lösung.

----------

## Aldo

Eine interessante Sprache ist auch "Brainfuck".

Siehe http://home.wxs.nl/~faase009/Ha_BF.html

----------

