TIA Siemens Simatic BugBounty Programm vorhanden?

Geextah

Level-2
Beiträge
12
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

gibt es von Siemens ein BugBounty Programm um Bugs/Exploits etc. zu melden? Ich bin beim Entwickeln meiner OPC Schnittstelle auf einen DOS Exploit gestoßen, wodurch die CPU in den Defekt Zustand wechselt und somit die komplette Anlage still legt.

Diagnosepuffer.png

1645179543134.png

Danke
Gruß Geextah
 
Version ist derzeit die v2.8. Habe eben beim Recherchieren gesehen das es zwischenzeitlich eine neuere Version gibt (v2.9.4 https://support.industry.siemens.co...mware-update-für-cpu-1515-2-pn?dti=0&lc=de-WW).
Sobald es die Anlage zulässt werden wir die Firmware mal hochrüsten und ich teste nochmal ob der Bug noch existent ist oder nicht.

Das dachte ich mir schon das Siemens nicht all zu viel Wert darauf legt..
Unter https://new.siemens.com/global/en/products/services/cert/hall-of-thanks.html gelistet zu werden ist natürlich schon erstrebenswert 😄 *ironie off* 🤦‍♂️
 
Version ist derzeit die v2.8. Habe eben beim Recherchieren gesehen das es zwischenzeitlich eine neuere Version gibt (v2.9.4
So ganz abwägig ist es nicht, dass dir ein FW-Update hilft,

hier nur mal die Info´s von V2.9.4:
Folgendes Verhalten wurde behoben:
  • Bei Aufnahme der Kommunikation zu einem PROFINET Device kommt es nicht mehr zu den sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00000265 16#1002000D 16#00000000)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00080001 16#1002FFFF 16#00000246)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Bei gleichzeitiger Verwendung von SFB 143 “ DataLogClear mit einer Anweisung aus der Gruppe „File handling“ („FileReadC“ oder „FileWriteC“), kommt es nicht mehr zu den sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#1002006F 16#7856D54C)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#1002006F 16#00010202)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Die mit SIMATIC WinCC Unified „View of Things“ erstellten Webseiten der CPU bringen keine Fehlermeldung mehr „invalid Tagname xxx“ wenn in der symbolischen Adresse UTF-8-Zeichen, wie z.B. chinesische Schriftzeichen, enthalten sind und das Adresselement nicht durch Anführungszeichen umklammert wurde.
  • Bei Zugriffen auf den Webserver der CPU kommt es nicht mehr zu den sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00080001 16#1002007B 16#E0042DB4)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00000038 16#10020000 16#00000000)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion) oder
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00080001 16#1002007B 16#E0042EA4)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Bei Verwendung sehr großer Bausteine kommt es nicht mehr sporadisch zum Kompilierungsfehler beim Download auf die CPU und anschließender Fehlermeldung:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#10020035 16#77D95B54)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Beim Auslösen von Alarmen kommt es nicht mehr zu sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#0FFF0000 16#10020000 16#00000000) CPU wechselt in DEFEKT-Zustand (Systemreaktion)
  • Bei Verwendung der Anweisung MC_SetAxisSTW kommt es nicht mehr zum Fehler 16#8FFF, wenn das Execute-Bit mit der fallenden Flanke des MC_Power.Enable gesetzt wird.
  • Bei Verwendung des Technologieobjektes TO_CamTrack in besonderen Szenarien kommt es nicht mehr zum fehlerhaften Schalten von Nocken.
  • Bei Verwendung der Anweisungen MC_OffsetRelative oder MC_OffsetAbsolute mit einem negativen Offset, die durch einen MC_OffsetRelative abgelöst werden, kommt es nicht mehr zu unerwünschten Bewegungen der Folgeachse.
  • Nach dem Hochrüsten eines Projektes auf Motion Control Version 6.0 kommt es bei Verwendung der Anwenderdefinierten Kinematik nicht mehr zu einem Nullpointer-Zugriff im OB MC-Transformation (OB98)
  • Beim intensiven Ändern von Dynamikwerten am TO-Kinematics kommt es nicht mehr zu sporadischen Fehlermeldungen:
    • Temporärer CPU-Fehler: Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#10020059 16#00010202)
      CPU wechselt in DEFEKT-Zustand (Systemreaktion)


Dann noch Info aus der V2.8.2 welche dich wohl mehr betreffen:
Folgendes Verhalten wurde behoben:
  • Es kommt nicht mehr dazu, dass nach einem Netz Aus / Netz Ein die CPU mit der Meldung „Warnung zu Remanenzdaten: Remanenzdaten verloren – Aktueller CPU-Betriebszustand: STOP (Initialisierung)“ in STOP geht und Daten, die als remanent gekennzeichnet wurden, verloren gehen, wenn in mehr als 1020 Datenbausteinen Daten als remanent deklariert wurden.
  • Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00000000 16#10020000 16#00000000) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn bei Anpassung der Initialwerte eines DBs ohne strukturelle Änderung des Inhalts oder bei Änderungen in der CPU-Meldeliste beim anschließenden Download ein Verbindungsabbruch in Kombination mit Motion- und F-Applikationen erfolgt ist.
  • Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#10020082 16#77A2A4D4) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn sich der OPC UA Client beim Beenden von Subscriptions nicht konform der OPC UA Spezifikation verhält.
  • Es kommt nicht mehr sporadisch zu der Meldung „Schwerwiegender Firmware-Ausnahmefehler (interner Systemcode: 16#00400001 16#1002003A 16#00010246) CPU wechselt in DEFEKT-Zustand (Systemreaktion)“, wenn der OPC UA Client auf der S7-1500 CPU versucht eine Variable zu lesen, die nicht konform der OPC UA Spezifikation als Instanz eines abstrakten Datentypen auf dem OPC UA Server angelegt worden ist.

usw...
 
Da sollte unser @ducati ja wohl hoffentlich gelistet sein wegen:
Wenn ein PEW als Eingang an einem FC nicht erreichbar ist, wird FC nicht bearbeitet

und der darauf folgenden Firmwareanpassung seitens Siemens ( V2.1 ):
Folgendes Verhalten wurde mit der FW 2.1 geändert:
  • Peripheriedirektzugriffe, die als Eingangsparameter an Bausteinen verschaltet sind, führen beim Auftreten eines Peripheriezugriffsfehlers nicht mehr dazu, dass der Baustein nicht mehr durchlaufen wird. Stattdessen wird mit dem Ersatzwert des Signals im Baustein gearbeitet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Schade das du den internen Systemcode ausgegraut hast, sonst könnte man eindeutiger bei den Firmwareupdates nachlesen.
Da ich nicht beurteilen kann, ob diese schon sicherheitsrelevante Informationen enthalten, hab ich sie lieber ausgegraut. Bei mir sind es insgesamt 3 Codes und nur einer davon hatte eine Übereinstimmung, somit wurde dieser Bug wohl noch nicht behoben.

Wir haben die Firmware soeben auf die v2.9.4 hochgerüstet und der Exploit ist noch vorhanden.
 
Du kannst sicher ein Case aufmachen und das dort melden, aber erwarte kein Danke, nicht von denen!
Ich hatte zwar noch keine Security-relevanten Sachen zu melden, da ich der Meinung bin dass man da bei den Siemens-Steuerungen sowieso nie fertig wird......

Mein letzter Versuch, einen Compiler-Bug zu melden (per Service-Request) endete darin, dass mich der Service-Mitarbeiter angeschnauzt hat, warum ich mich nicht an das Anwendungsbeispiel halte und dass meine Testkonfiguration ohnehin keine Praxisrelevanz hat......
 
Mein letzter Versuch, einen Compiler-Bug zu melden (per Service-Request) endete darin, dass mich der Service-Mitarbeiter angeschnauzt hat, warum ich mich nicht an das Anwendungsbeispiel halte und dass meine Testkonfiguration ohnehin keine Praxisrelevanz hat......
Ach, wie sich die Zeiten ändern. Ich kenne es noch so, dass meine Beschwerde über ein nicht funktionierendes Beispiel zu der Reaktion führte: "Das ist doch nur ein Beispiel!"
Keine PraxisRelevanz. Aha. Das sagen also diejenigen, die gar nicht wissen/ahnen, was in der Praxis (also gaaanz weit jenseits der Theorie) tatsächlich benötigt wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da sollte unser @ducati ja wohl hoffentlich gelistet sein wegen:
Wenn ein PEW als Eingang an einem FC nicht erreichbar ist, wird FC nicht bearbeitet

und der darauf folgenden Firmwareanpassung seitens Siemens ( V2.1 ):
Nee, ich tauch da nicht auf🤷‍♂️

War damals echt schwer, denen begreiflich zu machen, dass des überhaupt nen Bug war. Glaub letztendlich lief's über den Siemensvertriebler...
Normalerweise würd ich mir den Aufwand auch nicht mehr machen, und wir haben ja hier eh nen Workarround entwickelt, der bis heute läuft.
 
Vor vielen Jahren hatten wir eine S5-Positionierbaugruppe. Die war so buggy, dass sie manchmal falsche Bremswege berechnet hat, was zu schweren Unfällen hätte führen können. Um das nachzuweisen brauchten wir einen 8-Kanalschreiber, das war damals noch ein Riesenkasten, teuer, hatten wir nicht. Nach langen Verhandlungen mit Siemens borgten die uns einen unter der Maßgabe, "Ist es ein Bug, kostet uns die Leigabe nichts, ist es keiner müssen wir eine Leihgebühr zahlen!" Das war schon dreist. Wir haben den Bug gefunden, die haben ihn beseitigt, ich glaube, eine Danke kam nie. "Witzig" war, dass bei der übernächsten FW der Bug wieder drin war!
 
Um das nachzuweisen brauchten wir einen 8-Kanalschreiber, das war damals noch ein Riesenkasten, teuer, hatten wir nicht. Nach langen Verhandlungen mit Siemens borgten die uns einen unter der Maßgabe, "Ist es ein Bug, kostet uns die Leigabe nichts, ist es keiner müssen wir eine Leihgebühr zahlen!" Das war schon dreist. Wir haben den Bug gefunden, die haben ihn beseitigt, ich glaube, eine Danke kam nie.
Siemens leiht euch kostenlos einen schweineteueren Riesenkasten ... seid ihr denn auf die Idee gekommen, euch zu bedanken? :unsure:
"Witzig" war, dass bei der übernächsten FW der Bug wieder drin war!
Manche Bugs haben sich einfach so gut bewährt, die setzen sich immer wieder durch.
Bei Siemens gibt es keine Bugs, entweder ist es ein "Systemverhalten" oder ein "Anwenderfehler".
All die tollen Features nicht zu vergessen!
 
All die tollen Features nicht zu vergessen!

Das ist übrigens kein Scherz. Ich habe kürzlich ein Projekt gehabt, wo ich eine Liste mit Bugs gemacht habe die an Siemens gegangen ist, weil mich das etliche Stunden gekostet hat. Da wurde nichts angenommen, alles "kann nicht nachvollzogen werden", "Systemeigenschaft", oder "Anwenderfehler". Auch wenn es der Support vorerst eingesehen hat, aber wenn das an die übergeordnete Ebene geht, dann sehen die das anders.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hm. Jetzt hatte ich den Starter dieses Threads mal mit der Bitte um nähere Informationen angeschrieben und etwas gewartet, aber da kommt nichts. Das ist schade, denn ich hätte dafür sorgen können, dass der Fehler gefunden und behoben wird.
 
Hm. Jetzt hatte ich den Starter dieses Threads mal mit der Bitte um nähere Informationen angeschrieben und etwas gewartet, aber da kommt nichts. Das ist schade, denn ich hätte dafür sorgen können, dass der Fehler gefunden und behoben wird.
Nicht verzweifeln! Nichts ist so dringend, dass nicht etwas anderes, noch viel dringenderes, dazwischen kommen könnte.
Vielleicht ein Hilfeschrei eines Kunden angesichts eines MaschinenStillstandes oder Krankheit oder Urlaub oder ... .
Falls Du eine Chance siehst, auch ohne Rückfragen an den Themenstarter, hier im Forum für andere Interessierte/Betroffene den einen oder anderen hilfreichen Tipp zu hinterlassen, fell free to do it! ;)
 
Zurück
Oben