1 of 8

open-security-summit.org

All materials will be published under a CC  or open source license

ISG Track

TRAINING SESSIONS

What security exploits are prevented by implementing ISGs

2 of 8

Definitions from ISG

3 of 8

  • ISG should cover ALL elements of a file that has security side effects
  • If an exploit is done using a method/technique not covered by the ISG , that is vuln/gap in the ISG
  • A file that is ‘Spec compliant’ and ‘ISG compliant‘ should be safe
  • A file that is ‘NON Spec compliant’ but ‘ISG compliant‘ should be safe
  • A file that is ‘Spec compliant file’ but ‘NON ISG compliant‘ should be unsafe
  • What we want is to create ISG Compliant files and allow “Fact based Risk decisions’
  • There is lots of industry coverage/support for ‘NON Spec compliant’ files
  • ​

Definitions / Fact

Safe* = no exploits and no data leak�* see ISG Protects against section

4 of 8

​

  • High : ‘NON Spec compliant’ and ‘NON ISG compliant‘
  • Medium: ‘Spec compliant’ and ‘NON ISG compliant‘
  • Low : ‘NON Spec compliant’ and ‘ISG compliant‘
  • Lowest : ‘Spec compliant’ and ISG compliant‘

RISK of files�

5 of 8

  • Vulnerabilities in file parsers (unknown and known)
    • Research CVEs for examples
  • Crashes caused by malformed files
  • Masquerading files
    • Polyglot files
      • Phar
      • Gifar
    • Bypass file detection
  • Dangerous Functionality
  • Data Leaks

ISG Protects against

6 of 8

  • ...
  • ​

Risk of a file

7 of 8

  • One remit is to
    • look for “known good”.
    • Matching to file spec
  • ​

Notes

8 of 8

  • Buffer Overflows (Stack, Heap, Integer, String Format)
  • ​

exploits