The Perl Jam 2 (Allgemeines zu Perl) - Perl-Community.de

Start · Board · Anwendungen/Programme/Skripte in Perl · Allgemeines zu Perl

2024-11-24 07:42:23
Europe/Berlin
Einloggen (Registrieren)
- Einstellungen
- Statistics
Jemand zu Hause?
0 Benutzer online
3 Gäste

[thread]19927[/thread]

submit to reddit

The Perl Jam 2

Tags: perl5 Ähnliche Threads

Leser: 22

Articles: hide open all | hide show old branches

+25 replies
Raubtier

2015-12-17 14:04

User since
2012-05-04
1075 Artikel
BenutzerIn

Moin,

wie ich sehe, wird es auf dem diesjährigen Chaos Communication Congress einen Folgebeirag zum letztfärigen Perl Jam geben:
https://events.ccc.de/congress/2015/Fahrplan/event...

Weiß jemand zufällig, worum es dieses Mal geht?

(und ist jemand vor Ort?)
- Linuxer
  
  2015-12-17 14:45
  
  User since
  2006-01-27
  3890 Artikel
  HausmeisterIn
  
  Hm, steht doch - relativ kryptisch - im verlinkten Text, worum es geht.
  
  Quote
  Finding vulnerabilities in core modules is not enough. I need to prove there are problems in the most fundamental aspects of the Perl language, or the Perl community will keep ignoring the language many issues.
  ..
  and we are going to analyze it in a presentation filled with lolz, WATs, and 0-days, so maybe this time something will change
  ...
  
  Also sucht er anscheinend nach Fehlern und Problemen in Perl selbst. Allerdings ist sein Text recht verwirrend geschrieben (finde ich). Erst heisst es "Core-Module waren nicht genug", dann "jetzt geht's an den Kern selbst", um dann wieder auf Nicht-Kern-Module loszugehen...
  
  Netanel's Vortrag vom letzten Jahr war mir zu sehr FUD gewesen; ausserdem hatte er den Eindruck erweckt, nicht wirklich Erfahrung mit Perl zu haben (so war jedenfalls mein Eindruck, soweit ich mich erinnere). Zusammen mit der von der verlinkten Ankündigung erwarte ich ein weiteres FUD Kapitel von ihm.
  
  Seine Intention mag ja gut sein (so hoffe ich), aber er brachte es (IMHO) letztes Jahr nicht gut rüber und ich fürchte, er wird es auch dieses Jahr nicht hinkriegen. Aber vielleicht ist ja wirklich Inhalt in seinem FUD zu finden.
  
  (Nein, ich werde nicht vor Ort (auf dem Congress) sein.)
  meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
  Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
- Gast wer
  
  2015-12-17 15:33
  
  Die Themen beim letzten fand ich
  -nicht unterhaltsam
  -nicht reproduzierbar
  -nicht problematisch
  Kann mir nicht vorstellen das er sich dieses mal was besseres ausm xxx zieht.
  
  Es war nicht
  Quote
  it's illogical therefore it's bad design
  
  sondern
  Quote
  I din't know it, therefore it's wrong
  
  Last edited: 2015-12-17 16:05:15 +0100 (CET)
- +20 replies
- Raubtier
  
  2015-12-28 21:21
  
  User since
  2012-05-04
  1075 Artikel
  BenutzerIn
  
  So kurz zusammengefasst:
  Er hat 2 Punkte: erste Hälfte des Talks: komplett irrelevant - in Bugzilla wurde eine SQL-Injection gefunden, weil jemand nicht gequotet hat. (angeblich würden in der Perl-Community Werte aus Arrays und Hashes als "sicher" gelten - was für ein Blödsinn!)
  
  Zweiter Punkt: ein harmlos aussehendes Codestück mit CGI.pm, in dem Remote Code Execution möglich ist. Das war schon interessanter. Punkt ist, dass $fh = $cgi->upload("file") bei mehreren file-Argumenten das erste dann in $fh speichert und wenn man dann "ARGV" als Namen nimmt und eine unschuldige "while(<$fh>)"-Schleife hat, man verloren hat. (allerdings geht das wohl nicht im Taint-Mode).
  - +19 replies
  - Gast wer
    
    2015-12-30 01:31
    Naja, das ganze löst sich in Wohlgefallen auf, wenn man es so macht:
    
    Code (perl): (dl )
    
    1 2 3 4 5
    
    if(my $fh = $cgi->upload('upload_file')) { while(<$fh>) { # ... } }
    
    oder
    
    Code (perl): (dl )
    
    1 2 3 4 5 6 7
    
    if(my @fh_list = $cgi->upload('upload_file')) { for my $fh ( @fh_list ) { while(<$fh>) { # ... } } }
    
    So steht es auch so in der Doku:
    
    Code (perl): (dl )
    
    if ( my $io_handle = $q->upload('field_name') ) {
    
    Ja es ist problematisch , das $cgi->param( ... ) auch das filehandle zurück gibt und nicht nur den Dateinamen. Aber genau das sind die Gründe warum man CGI im allgemeinen nicht mehr verwenden sollte.
    Last edited: 2015-12-30 09:08:19 +0100 (CET)
    - +5 replies
    - Gast janus
      
      2015-12-30 11:08
      
      Die Überlagerung von Dateiname und Handle war noch nie das Problem. Auch dann nicht, wenn das Atribut multiple gesetzt wurde. Allerdings fand ich es schon immer unsinnig, dass CGI.pm beim Upload temporäre Dateien anlegt. Und überhaupt gehört der Enctype multipart/form-data längst auf den Müllhaufen der Geschichte. Weil es ein unglaublicher Unfug ist, Binärdaten mit einer Boundary zu trennen. Demenstprechend umständlich ist das Parsen.
      
      Moderne Browser unterstützen mittlerweile Binaries in JavaScript. Das erlaubt multiple Uploads unter Verzicht auf den Enctype multipart/form-data. Vorausgesetzt, die Sequenzen wurden zweckentsprechend serialisiert und wenn mit Längenangaben gearbeitet wurde, ist die Wiederherstellung der Binaries serverseitig überhaupt kein Problem, keine Boundary und auch keine temporären Dateien.
      
      In Fakt sind das freilich alles keine Probleme die Perl spezifisch sind. Problematisch wirds nur immer dann, wenn die Dokumentation nicht richtig gelesen und nicht verstanden wurde.
      Last edited: 2015-12-30 12:02:06 +0100 (CET)
      - +4 replies
      - topeg
        
        2015-01-03 21:03
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        CGI.pm wurde zu Zeiten entworfen und geschrieben in denen Scripte nur ein paar KB Speicher belegen durften. große Dateien lassen sich da nur über externen Speicher lesen und verarbeiten. Darum die Geschichte mit den temporären Dateien. Seit damals hat sich einiges getan und heute dürfen Prozesse auch gerne mal mehrere Gb Ram belegen. Aber nachträglich das komplette Design von CGI verändern geht auch nicht da es durchaus Scripte gibt, welche die Temporären Dateien direkt benutzten und nicht die Filehandles.
        Moderne Module bieten darum Hooks für File-Transfers. Mit denen kann man selber entscheiden wie Dateien behandelt werden sollten.
        
        multipart/form-data halte ich nicht für obsolete. Und sonderlich schwer zu Parsen ist es auch nicht. Es ist halt ein hierarchisches und sequenzielles Format. Der Sequenztrenner ist frei wählbar sodass er nicht dem binären Inhalt kollidiert. Der Inhalt-Body muss auch nicht Speziell kodiert und kann Binär übertragen werden. Ich sehe nicht was für einen direkten Vorteil ein proprietäres Format bieten sollte, außer das es mit etwas weniger Overhead auskommen mag.
        
        +3 replies
        
        Gast janus
        
        2015-01-03 21:28
        
        Der Enctype multipart/form-data ist eine Lachnummer. Es kann Kollisionen mit der Boundary geben, aber die Wahrscheinlichkeit ist gering. Das Parsen ist umständlich und wer schonmal selbst Serializer entwickelt hat, wird sofort sehen, dass allein eine Längenangabe für jeden Part die Boundary überflüssig machen würde. Längenangaben würden auch die Performance beim Deserialisieren verbessern, somit könnte die Boundary (Part) als EIN BLock gelesen werden.
        
        So wie es ist, kann die Datei nur in Schritten von 1 Byte gelesen werden und wenn die Boundary erkannt wurde, muss die akkumulierte Binary wieder gekürzt werden. Wie solch Enctype als Quasi-Standard sich solange halten konnte, ist mir ein Rätsel. So ein Schrott.
        Last edited: 2015-01-03 22:06:58 +0100 (CET)
        
        +2 replies
        
        betterworld
        
        2015-01-03 22:16
        
        User since
        2003-08-21
        2614 Artikel
        ModeratorIn
        
        Guest janus
        So wie es ist, kann die Datei nur in Schritten von 1 Byte gelesen werden und wenn die Boundary erkannt wurde, muss die akkumulierte Binary wieder gekürzt werden.
        
        Ich würde die Datei blockweise verarbeiten und nach jedem Block die Boundary suchen.
        
        Längenangaben haben den Nachteil, dass die Dateien dann schlecht menschenlesbar sind, das gibt Probleme beim Debugging.
        
        Ich habe sowas aber noch nie programmiert. Muss ich aber auch nicht, denn wenn sowas ordentlich in einem Framework gekapselt ist, läuft es ziemlich problemlos, und der normale Programmierer muss sich nicht mit den Feinheiten der Kodierung befassen.
        Lieblingsmodule: IPC::System::Simple, Path::Class
        
        Gast janus
        
        2016-01-04 08:10
        
        Für was um Himmels Willen muss die Datei menschenlesbar sein!?
        Last edited: 2016-01-04 09:38:21 +0100 (CET)
    - +13 replies
    - bianca
      
      2015-01-03 17:25
      
      User since
      2009-09-13
      7016 Artikel
      BenutzerIn
      
      Ich verstehe hier nicht so ganz, was hier der entscheidende Punkt für ein Sicherheitsproblem ist. Geht es um die Schleife oder die Abfragen oder was genau?
      
      Anders gefragt, gibt es ein Problem, wenn man es wie folgt macht?
      
      Code (perl): (dl )
      
      1 2 3 4
      
      if (my $temp = $cgi->upload('upload')) { local $/ = undef; $var = <$temp>; }
      
      Mit der Bitte um kurze Erläuterung.
      10 print "Hallo"
      20 goto 10
      - +12 replies
      - topeg
        
        2015-01-03 20:35
        
        User since
        2006-07-10
        2611 Artikel
        BenutzerIn
        
        CGI.pm speichert intern alle Werte zu einem Parameter in einem HoA. Ist nun der erste Wert zu einem Parameter "ARGV" und der zweite Wert eine Datei (beides als POST-Parameter), so gibt $cgi->upload('<Parameter>') "true" (nicht leere Liste von Filehandles) zurück, ( if($cgi->upload('<Parameter>')){ ... } ) weil ein Wert halt eine Datei ist, aber $cgi->param('<Parameter>') gibt "ARGV" zurück. Nun wäre das nicht so wild wenn nicht <ARGV> und $x='ARGV'; <$x> für Perl das gleiche wäre. Es wird nun alles geöffnet was in @ARGV als Datei erkannt wird. Und üblicherweise steht in bei einem CGI-Script in @ARGV die GET-Parameter. Wenn nun in @ARV noch "<programm> |" steht wird das entsprechende Programm gestartet.
        
        ABER
        
        Das ganze Problem löst sich in Wohlgefallen auf wenn man CGI.pm wie vorgesehen benutzt, indem man nur das als Filehandle benutzt was von $cgi->upload('<Parameter>') zurück gegeben wird. So ist es in CGI.pm dokumentiert und empfohlen. Also so
        
        Code (perl): (dl )
        
        1 2 3 4
        
        if (my $fh = $cgi->upload('upload')) { local $/ = undef; $var = <$fh>; }
        
        hat man keine Probleme.
        
        +9 replies
        
        Gast janus
        
        2015-01-03 21:12
        
        In @ARGV stehen GET-Parameter? Ich hab das grad getestet und konstatiere, dass das bei mir NICHT der Fall ist.
        
        Wer kommt denn überhaupt auf die Idee, in Webanwendungen @ARGV zu befragen? Auf die Idee bin ich noch NIE gekommen.
        
        Der Common Gateway Standard CGI/1.1 beschreibt doch eindeutig, dass Daten (Parameter) entweder aus dem URI (QUERY_STRING) oder aus STDIN gelesen werden. Stehen Daten in STDIN, setzt der Webserver eine Variable CONTENT_LENGTH. Das ist unabhängig von der REQUEST_METHOD und auch unabhängig vom Enctype (Content-Type) welchen der HTTPCLient sendet.
        
        MfG.
        Last edited: 2015-01-03 21:20:01 +0100 (CET)
        
        +8 replies
        
        pq
        
        2015-01-03 22:35
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        ARGV ist Teil der CGI-Spezifikation.
        
        http://server.example/blubb.cgi?foo+boo
        -->
        @ARGV = qw/ foo boo /
        
        egal, ob bei GET oder POST. nennt sich 'isindex' query.
        
        http://www.gnu.org/software/cgicc/doc/cgi_overview...
        Last edited: 2015-01-03 22:36:35 +0100 (CET)
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        Gast janus
        
        2016-01-04 08:19
        
        2016-01-03T21:35:29 pq
        ARGV ist Teil der CGI-Spezifikation.
        
        Ganz bestimmt nicht.
        
        Quote
        http://server.example/blubb.cgi?foo+boo
        
        Das ist URI Spezifikation. QUERY_STRING
        
        Und CGI/1.1 beschreibt doch den Datenfluss: STDIN, STDOUT, ENV (QUERY_STRING). Webserver und Script kommunizieren nicht über die Command-Line.
        Last edited: 2016-01-04 09:38:13 +0100 (CET)
        
        +6 replies
        
        Gast janus
        
        2016-01-04 08:31
        
        https://www.ietf.org/rfc/rfc3875
        
        Quote
        the
        ... server MUST NOT generate any command line information.
        
        Auf jeden Fall muss ein Server der CGI/1.1 implementiert die dafür vorgesehenen ENV Variablen setzen. Im Fall ?foo+bar+baz ist das der QUERY_STRING
        Last edited: 2016-01-04 09:38:08 +0100 (CET)
        
        +3 replies
        
        Gast wer
        
        2016-01-04 14:30
        
        Ja genau und vor 2004 gab es keine CGI-Scripte.
        
        Entwickelt wurde es für den „Ur-Webserver“ NCSA HTTPd und war in dieser Form lange Zeit ein de-facto Standard ohne RFC.
        
        Ursprünglich war es für Shell-Scripte geplant, die nur eingeschränkte parsing Fähigkeiten haben. Darum auch die optionale Übergabe per @ARGV.
        Last edited: 2016-01-04 14:43:25 +0100 (CET)
        
        +2 replies
        
        Gast janus
        
        2016-01-04 14:51
        
        Guest wer
        Ja genau und vor 2004 gab es keine CGI-Scripte.
        
        Entwickelt wurde es für den „Ur-Webserver“ NCSA HTTPd und war in dieser Form lange Zeit ein de-facto Standard ohne RFC.
        
        Ursprünglich war es für Shell-Scripte geplant, die nur eingeschränkte parsing Fähigkeiten haben. Darum auch die optionale Übergabe per @ARGV.
        
        Unsinn. CGI/1.1 ist um 1995 als Standard entwickelt worden.
        Last edited: 2016-01-04 14:54:16 +0100 (CET)
        
        Gast wer
        
        2016-01-04 15:17
        
        Natürlich wirft ein Update von 1.0 auf 1.1 alles über den Haufen was vorher definiert wurde und @ARGV wird nicht mehr verwendet...
        
        Weiterhin schau mal wann der NCSA's HTTPD Server entwickelt wurde und welche Verbreitung er hatte, bevor die Entwicklung eingestellt wurde.
        Und dann sage mir wer die CGI 1.0 und CGI 1.1 Spezifikationen geschrieben hat.
        Last edited: 2016-01-04 15:43:33 +0100 (CET)
        
        +2 replies
        
        Gast wer
        
        2016-01-04 14:47
        
        Und übrigens hast du Quotemining betieben:
        
        page-21 §4.4. The Script Command Line:
        
        Quote
        Some systems support a method for supplying an array of strings to
        the CGI script. This is only used in the case of an 'indexed' HTTP
        query, which is identified by a 'GET' or 'HEAD' request with a URI
        query string that does not contain any unencoded "=" characters. For
        such a request, the server SHOULD treat the query-string as a
        search-string and parse it into words, using the rules
        
        Code: (dl )
        
        1 2 3 4 5
        
        search-string = search-word *( "+" search-word ) search-word = 1*schar schar = unreserved | escaped | xreserved xreserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "," | "$"
        
        After parsing, each search-word is URL-decoded, optionally encoded in
        a system-defined manner and then added to the command line argument
        list.
        
        If the server cannot create any part of the argument list, then the
        server MUST NOT generate any command line information. For example,
        the number of arguments may be greater than operating system or
        server limits, or one of the words may not be representable as an
        argument.
        
        The script SHOULD check to see if the QUERY_STRING value contains an
        unencoded "=" character, and SHOULD NOT use the command line
        arguments if it does.
        
        Unehrlich, sehr Unehrlich.
        Last edited: 2016-01-04 14:53:59 +0100 (CET)
        
        Gast janus
        
        2016-01-04 15:06
        
        Also, mal ganz ehrlich: Wenn ein verantwortungsloser Provider den query_string auf die Kommandozeile umlegt und es ein paar Deppen gibt, die in ihren CGI-Scripts in das Array @ARGV greifen, heißt das doch noch lange nicht, dass Perl ein Sicherhitsproblem hat!
        Last edited: 2016-01-04 15:12:10 +0100 (CET)
        
        +2 replies
        
        bianca
        
        2015-01-03 21:39
        
        User since
        2009-09-13
        7016 Artikel
        BenutzerIn
        
        Danke für die Erklärung.
        
        Aber das mit den GET Parametern in @ARGV wäre mir auch neu ohne es jetzt getestet zu haben. Bist du da sicher?
        10 print "Hallo"
        20 goto 10
        
        Gast janus
        
        2016-01-04 12:55
        
        Es ist eine Frage der Serverkonfiguration, ob der query_string auf die Kommandozeile umgelegt wird. Ein halbwegs sicher denkender Provider wird sowas nicht machen. Es ist ein Sicherheitsrisiko, das hat mit Perl überhaupt nichts zu tun.
        
        Schöne Grüße.
        Last edited: 2016-01-04 12:59:04 +0100 (CET)
- +2 replies
- borisd
  
  2015-12-29 11:45
  
  User since
  2014-04-23
  15 Artikel
  BenutzerIn
  
  Der Vollständigkeit halber...
  
  Vortrag:
  https://live.dus.c3voc.de/relive//32c3/7130/muxed....
  
  Eine Antwort:
  http://blogs.perl.org/users/joel_berger/2015/12/re...
  - hlubenow
    
    2015-01-03 18:45
    
    User since
    2009-02-22
    875 Artikel
    BenutzerIn
    
    Joel Berger
    Given the embarrassing talk that Netanel Rubin gave last year, in which he chose not to learn a language and then laugh at it for the mistakes he made, I’m surprised I have to respond to yet another of his talks. ...
    This year Netanel found two things and ran with them past the point of absurdity
    
    Ich kann verstehen, wenn man gelegentlich sauer wird, aber besser finde ich eigentlich die Haltung aus dem Vorwort von "Programming Perl":
    
    Larry Wall
    You can program in Perl Baby-Talk, and we promise not to laugh. Or more precisely, we promise not to laugh any more than we'd giggle at a child's creative way of putting things.
    
    Das gilt natürlich auch, wenn der Code noch nicht "creative", sondern einfach fehlerhaft ist.

View all threads created 2015-12-17 14:04.