diff --git a/defensive-coding/en-US/Book_Info.xml b/defensive-coding/en-US/Book_Info.xml index 6637802..e631c6d 100644 --- a/defensive-coding/en-US/Book_Info.xml +++ b/defensive-coding/en-US/Book_Info.xml @@ -4,10 +4,10 @@ Defensive Coding A Guide to Improving Software Security - 1.0 - 1.0 + 1 + - + Fedora Security Team diff --git a/defensive-coding/tmp/en-US/html/Common_Content/css/common.css b/defensive-coding/tmp/en-US/html/Common_Content/css/common.css deleted file mode 100644 index d7dc3f2..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/css/common.css +++ /dev/null @@ -1,1528 +0,0 @@ -* { - widows: 2 !important; - orphans: 2 !important; -} - -body, h1, h2, h3, h4, h5, h6, pre, li, div { - line-height: 1.29em; -} - -body { - background-color: white; - margin:0 auto; - font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif; - font-size:12px; - max-width:55em; - color:black; -} - -body.toc_embeded { - /*for web hosting system only*/ - margin-left: 300px; -} - -object.toc, iframe.toc { - /*for web hosting system only*/ - border-style:none; - position:fixed; - width:290px; - height:99.99%; - top:0; - left:0; - z-index: 100; - border-style:none; - border-right:1px solid #999; -} - -/* Hide web menu */ - -body.notoc { - margin-left: 3em; -} - -iframe.notoc { - border-style:none; - border: none; - padding: 0em; - position:fixed; - width: 21px; - height: 29px; - top: 0px; - left:0; - overflow: hidden; - margin: 0em; - margin-left: -3px; -} -/* End hide web menu */ - -/* desktop styles */ -body.desktop { - margin-left: 26em; -} - -body.desktop .book > .toc { - display:block; - width:24em; - height:99%; - position:fixed; - overflow:auto; - top:0px; - left:0px; - padding-left:1em; - background-color:#EEEEEE; -} - -.toc { - line-height:1.35em; -} - -.toc .glossary, -.toc .chapter, .toc .appendix { - margin-top:1em; -} - -.toc .part { - margin-top:1em; - display:block; -} - -span.glossary, -span.appendix { - display:block; - margin-top:0.5em; -} - -div { - padding-top:0px; -} - -div.section { - padding-top:1em; -} - -p, div.para, div.formalpara { - padding-top:0px; - margin-top:0.3em; - padding-bottom:0px; - margin-bottom:1em; -} - -/*Links*/ -a { - outline: none; -} - -a:link { - text-decoration:none; - border-bottom: 1px dotted ; - color:#3366cc; -} - -a:visited { - text-decoration:none; - border-bottom: 1px dotted ; - color:#003366; -} - -div.longdesc-link { - float:right; - color:#999; -} - -.toc a, .qandaset a { - font-weight:normal; - border:none; -} - -.toc a:hover, .qandaset a:hover -{ - border-bottom: 1px dotted; -} - -/*headings*/ -h1, h2, h3, h4, h5, h6 { - color: #336699; - margin-top: 0em; - margin-bottom: 0em; - background-color: transparent; - page-break-inside: avoid; - page-break-after: avoid; -} - -h1 { - font-size:2.0em; -} - -.titlepage h1.title { - font-size: 3.0em; - padding-top: 1em; - text-align:left; -} - -.book > .titlepage h1.title { - text-align:center; -} - -.article > .titlepage h1.title { - text-align:center; -} - -.set .titlepage > div > div > h1.title { - text-align:center; -} - -.producttitle { - margin-top: 0em; - margin-bottom: 0em; - font-size: 3.0em; - font-weight: bold; - background: #003d6e url(../images/h1-bg.png) top left repeat-x; - color: white; - text-align: center; - padding: 0.7em; -} - -.titlepage .corpauthor { - margin-top: 1em; - text-align: center; -} - -.section h1.title { - font-size: 1.6em; - padding: 0em; - color: #336699; - text-align: left; - background: white; -} - -h2 { - font-size:1.6em; -} - - -h2.subtitle, h3.subtitle { - margin-top: 1em; - margin-bottom: 1em; - font-size: 1.4em; - text-align: center; -} - -.preface > div > div > div > h2.title { - margin-top: 1em; - font-size: 2.0em; -} - -.appendix h2 { - margin-top: 1em; - font-size: 2.0em; -} - - - -h3 { - font-size:1.3em; - padding-top:0em; - padding-bottom:0em; -} -h4 { - font-size:1.1em; - padding-top:0em; - padding-bottom:0em; -} - -h5 { - font-size:1em; -} - -h6 { - font-size:1em; -} - -h5.formalpara { - font-size:1em; - margin-top:2em; - margin-bottom:.8em; -} - -.abstract h6 { - margin-top:1em; - margin-bottom:.5em; - font-size:2em; -} - -/*element rules*/ -hr { - border-collapse: collapse; - border-style:none; - border-top: 1px dotted #ccc; - width:100%; - margin-top: 3em; -} - -/* web site rules */ -ul.languages, .languages li { - display:inline; - padding:0em; -} - -.languages li a { - padding:0em .5em; - text-decoration: none; -} - -.languages li p, .languages li div.para { - display:inline; -} - -.languages li a:link, .languages li a:visited { - color:#444; -} - -.languages li a:hover, .languages li a:focus, .languages li a:active { - color:black; -} - -ul.languages { - display:block; - background-color:#eee; - padding:.5em; -} - -/*supporting stylesheets*/ - -/*unique to the webpage only*/ -.books { - position:relative; -} - -.versions li { - width:100%; - clear:both; - display:block; -} - -a.version { - font-size:2em; - text-decoration:none; - width:100%; - display:block; - padding:1em 0em .2em 0em; - clear:both; -} - -a.version:before { - content:"Version"; - font-size:smaller; -} - -a.version:visited, a.version:link { - color:#666; -} - -a.version:focus, a.version:hover { - color:black; -} - -.books { - display:block; - position:relative; - clear:both; - width:100%; -} - -.books li { - display:block; - width:200px; - float:left; - position:relative; - clear: none ; -} - -.books .html { - width:170px; - display:block; -} - -.books .pdf { - position:absolute; - left:170px; - top:0px; - font-size:smaller; -} - -.books .pdf:link, .books .pdf:visited { - color:#555; -} - -.books .pdf:hover, .books .pdf:focus { - color:#000; -} - -.books li a { - text-decoration:none; -} - -.books li a:hover { - color:black; -} - -/*products*/ -.products li { - display: block; - width:300px; - float:left; -} - -.products li a { - width:300px; - padding:.5em 0em; -} - -.products ul { - clear:both; -} - -/*revision history*/ -.revhistory { - display:block; -} - -.revhistory table { - background-color:transparent; - border-color:#fff; - padding:0em; - margin: 0; - border-collapse:collapse; - border-style:none; -} - -.revhistory td { - text-align :left; - padding:0em; - border: none; - border-top: 1px solid #fff; - font-weight: bold; -} - -.revhistory .simplelist td { - font-weight: normal; -} - -.revhistory .simplelist { - margin-bottom: 1.5em; - margin-left: 1em; -} - -.revhistory table th { - display: none; -} - - -/*credits*/ -.authorgroup div { - clear:both; - text-align: center; -} - -h3.author { - margin: 0em; - padding: 0em; - padding-top: 1em; -} - -.authorgroup h4 { - padding: 0em; - margin: 0em; - padding-top: 1em; - margin-top: 1em; -} - -.author, -.editor, -.translator, -.othercredit, -.contrib { - display: block; -} - -.revhistory .author { - display: inline; -} - -.othercredit h3 { - padding-top: 1em; -} - - -.othercredit { - margin:0em; - padding:0em; -} - -.releaseinfo { - clear: both; -} - -.copyright { - margin-top: 1em; -} - -/* qanda sets */ -.answer { - margin-bottom:1em; - border-bottom:1px dotted #ccc; -} - -.qandaset .toc { - border-bottom:1px dotted #ccc; -} - -.question { - font-weight:bold; -} - -.answer .data, .question .data { - padding-left: 2.6em; -} - -.answer label, .question label { - float:left; - font-weight:bold; -} - -/* inline syntax highlighting */ -.perl_Alert { - color: #0000ff; -} - -.perl_BaseN { - color: #007f00; -} - -.perl_BString { - color: #5C3566; -} - -.perl_Char { - color: #ff00ff; -} - -.perl_Comment { - color: #FF00FF; -} - - -.perl_DataType { - color: #0000ff; -} - - -.perl_DecVal { - color: #00007f; -} - - -.perl_Error { - color: #ff0000; -} - - -.perl_Float { - color: #00007f; -} - - -.perl_Function { - color: #007f00; -} - - -.perl_IString { - color: #5C3566; -} - - -.perl_Keyword { - color: #002F5D; -} - - -.perl_Operator { - color: #ffa500; -} - - -.perl_Others { - color: #b03060; -} - - -.perl_RegionMarker { - color: #96b9ff; -} - - -.perl_Reserved { - color: #9b30ff; -} - - -.perl_String { - color: #5C3566; -} - - -.perl_Variable { - color: #0000ff; -} - - -.perl_Warning { - color: #0000ff; -} - -/*Lists*/ -ul { - padding-left:1.6em; - list-style-image:url(../images/dot.png); - list-style-type: circle; -} - -ul ul { - list-style-image:url(../images/dot2.png); - list-style-type: circle; -} - -ol { - list-style-image:none; - list-style-type: decimal; -} - -ol ol { - list-style-type: lower-alpha; -} - -ol.arabic { - list-style-type: decimal; -} - -ol.loweralpha { - list-style-type: lower-alpha; -} - -ol.lowerroman { - list-style-type: lower-roman; -} - -ol.upperalpha { - list-style-type: upper-alpha; -} - -ol.upperroman { - list-style-type: upper-roman; -} - -dt { - font-weight:bold; - margin-bottom:0em; - padding-bottom:0em; -} - -dd { - margin:0em; - margin-left:2em; - padding-top:0em; - padding-bottom: 1em; -} - -li { - padding-top:0px; - margin-top:0em; - padding-bottom:0px; - margin-bottom:0.4em; -} - -li p, li div.para { - padding-top:0px; - margin-top:0em; - padding-bottom:0px; - margin-bottom:0.3em; -} - -/*images*/ -img { - display:block; - margin: 2em 0; -} - -.inlinemediaobject, .inlinemediaobject img { - display:inline; - margin:0em; -} - -.figure img { - display:block; - margin:0; - page-break-inside: avoid; -} - -.figure .title { - margin:0em; - margin-bottom:2em; - padding:0px; -} - -/*document modes*/ -.confidential { - background-color:#900; - color:White; - padding:.5em .5em; - text-transform:uppercase; - text-align:center; -} - -.longdesc-link { - display:none; -} - -.longdesc { - display:none; -} - -.prompt { - padding:0em .3em; -} - -/*user interface styles*/ -.screen .replaceable { -} - -.guibutton, .guilabel { - font-family: "liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-weight: bold; - white-space: nowrap; -} - -.example { - background-color: #ffffff; - border-left: 3px solid #aaaaaa; - padding-top: 1em; - padding-bottom: 0.1em; -} - -.example h6 { - padding-left: 10px; -} - -.example-contents { - padding-left: 10px; - background-color: #ffffff; -} - -.example-contents .para { -/* padding: 10px;*/ -} - -/*terminal/console text*/ -.computeroutput, -.option { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-weight:bold; -} - -.replaceable { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-style: italic; -} - -.command, .filename, .keycap, .classname, .literal { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-weight:bold; -} - -/* no bold in toc */ -.toc * { - font-weight: inherit; -} - -pre { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - display:block; - background-color: #f5f5f5; - color: #000000; - border: 1px solid #aaaaaa; - margin-bottom: 0.3em; - padding:.5em 1em; - white-space: pre-wrap; /* css-3 */ - white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */ - white-space: -pre-wrap; /* Opera 4-6 */ - white-space: -o-pre-wrap; /* Opera 7 */ - word-wrap: break-word; /* Internet Explorer 5.5+ */ - font-size: 0.9em; -} - -pre .replaceable, -pre .keycap { -} - -code { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; -/* white-space: nowrap;*/ - white-space: pre-wrap; - word-wrap: break-word; - font-weight:bold; -} - -.parameter code { - display: inline; - white-space: pre-wrap; /* css-3 */ - white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */ - white-space: -pre-wrap; /* Opera 4-6 */ - white-space: -o-pre-wrap; /* Opera 7 */ - word-wrap: break-word; /* Internet Explorer 5.5+ */ -} - -/*Notifications*/ -div.warning:before { - content:url(../images/warning.png); - padding-left: 5px; -} - -div.note:before { - content:url(../images/note.png); - padding-left: 5px; -} - -div.important:before { - content:url(../images/important.png); - padding-left: 5px; -} - -div.warning, div.note, div.important { - color: black; - margin: 0em; - padding: 0em; - background: none; - background-color: white; - margin-bottom: 1em; - border-bottom: 1px solid #aaaaaa; - page-break-inside: avoid; -} - -div.warning h2, div.note h2,div.important h2 { - margin: 0em; - padding: 0em; - color: #eeeeec; - padding-top: 0px; - padding-bottom: 0px; - height: 1.4em; - line-height: 1.4em; - font-size: 1.4em; - display:inline; -} - -div.admonition_header { - clear: both; - margin: 0em; - padding: 0em; - margin-top: -3.3em; - padding-left: 58px; - line-height: 1.0em; - font-size: 1.0em; -} - -div.warning div.admonition_header { - background: url(../images/red.png) top left repeat-x; - background-color: #590000; -} - -div.note div.admonition_header { - background: url(../images/green.png) top right repeat-x; - background-color: #597800; -} - -div.important div.admonition_header { - background: url(../images/yellow.png) top right repeat-x; - background-color: #a6710f; -} - -div.warning p, div.warning div.para, -div.note p, div.note div.para, -div.important p, div.important div.para { - padding: 0em; - margin: 0em; -} - -div.admonition { - border: none; - border-left: 1px solid #aaaaaa; - border-right: 1px solid #aaaaaa; - padding:0em; - margin:0em; - padding-top: 1.5em; - padding-bottom: 1em; - padding-left: 2em; - padding-right: 1em; - background-color: #eeeeec; - -moz-border-radius: 0px; - -webkit-border-radius: 0px; - border-radius: 0px; -} - -/*Page Title*/ -#title { - display:block; - height:45px; - padding-bottom:1em; - margin:0em; -} - -#title a.left{ - display:inline; - border:none; -} - -#title a.left img{ - border:none; - float:left; - margin:0em; - margin-top:.7em; -} - -#title a.right { - padding-bottom:1em; -} - -#title a.right img { - border:none; - float:right; - margin:0em; - margin-top:.7em; -} - -/*Table*/ -div.table { - page-break-inside: avoid; -} - -table { - border:1px solid #6c614b; - width:100%; - border-collapse:collapse; -} - -table.simplelist, .calloutlist table { - border-style: none; -} - -table th { - text-align:left; - background-color:#6699cc; - padding:.3em .5em; - color:white; -} - -table td { - padding:.15em .5em; -} - -table tr.even td { - background-color:#f5f5f5; -} - -table th p:first-child, table td p:first-child, table li p:first-child, -table th div.para:first-child, table td div.para:first-child, table li div.para:first-child { - margin-top:0em; - padding-top:0em; - display:inline; -} - -th, td { - border-style:none; - vertical-align: top; - border: 1px solid #000; -} - -.simplelist th, .simplelist td { - border: none; -} - -table table td { - border-bottom:1px dotted #aaa; - background-color:white; - padding:.6em 0em; -} - -table table { - border:1px solid white; -} - -td.remarkval { - color:#444; -} - -td.fieldval { - font-weight:bold; -} - -.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost { - color:white; - font-weight:bold; - background-color:#999; - width:120px; -} - -td.remarkval { - width:230px; -} - -td.tname { - font-weight:bold; -} - -th.dbfield { - width:120px; -} - -th.dbtype { - width:70px; -} - -th.dbdefault { - width:70px; -} - -th.dbnul { - width:70px; -} - -th.dbkey { - width:70px; -} - -span.book { - margin-top:4em; - display:block; - font-size:11pt; -} - -span.book a{ - font-weight:bold; -} -span.chapter { - display:block; - margin-top:0.5em; -} - -table.simplelist td, .calloutlist table td { - border-style: none; -} - -/*Breadcrumbs*/ -#breadcrumbs ul li.first:before { - content:" "; -} - -#breadcrumbs { - color:#900; - padding:3px; - margin-bottom:25px; -} - -#breadcrumbs ul { - margin-left:0; - padding-left:0; - display:inline; - border:none; -} - -#breadcrumbs ul li { - margin-left:0; - padding-left:2px; - border:none; - list-style:none; - display:inline; -} - -#breadcrumbs ul li:before { - content:"\0020 \0020 \0020 \00BB \0020"; - color:#333; -} - -/*index*/ -.glossary h3, -.index h3 { - font-size: 2em; - color:#aaa; - margin:0em; -} - -.indexdiv { - margin-bottom:1em; -} - -.glossary dt, -.index dt { - color:#444; - padding-top:.5em; -} - -.glossary dl dl dt, -.index dl dl dt { - color:#777; - font-weight:normal; - padding-top:0em; -} - -.index dl dl dt:before { - content:"- "; - color:#ccc; -} - -/*changes*/ -.footnote { - font-size: .7em; - margin:0em; - color:#222; -} - -table .footnote { -} - -sup { - color:#999; - margin:0em; - padding:0em; - line-height: .4em; - font-size: 1em; - padding-left:0em; -} - -.footnote { - position:relative; -} - -.footnote sup { - color:#e3dcc0; - position:absolute; - left: .4em; -} - -.footnote sup a:link, -.footnote sup a:visited { - color:#92917d; - text-decoration:none; -} - -.footnote:hover sup a { - text-decoration:none; -} - -.footnote p,.footnote div.para { - padding-left:2em; -} - -.footnote a:link, -.footnote a:visited { - color:#00537c; -} - -.footnote a:hover { -} - -/**/ -div.chapter { - margin-top:3em; - page-break-inside: avoid; -} - -div.preface { - page-break-inside: avoid; -} - -div.section { - margin-top:1em; - page-break-inside: auto; -} - -div.note .replaceable, -div.important .replaceable, -div.warning .replaceable, -div.note .keycap, -div.important .keycap, -div.warning .keycap -{ -} - -ul li p:last-child, ul li div.para:last-child { - margin-bottom:0em; - padding-bottom:0em; -} - -/*document navigation*/ -.docnav a, .docnav strong { - border:none; - text-decoration:none; - font-weight:normal; -} - -.docnav { - list-style:none; - margin:0em; - padding:0em; - position:relative; - width:100%; - padding-bottom:2em; - padding-top:1em; - border-top:1px dotted #ccc; -} - -.docnav li { - list-style:none; - margin:0em; - padding:0em; - display:inline; - font-size:.8em; -} - -.docnav li:before { - content:" "; -} - -.docnav li.previous, .docnav li.next { - position:absolute; - top:1em; -} - -.docnav li.up, .docnav li.home { - margin:0em 1.5em; -} - -.docnav li.previous { - left:0px; - text-align:left; -} - -.docnav li.next { - right:0px; - text-align:right; -} - -.docnav li.previous strong, .docnav li.next strong { - height:22px; - display:block; -} - -.docnav { - margin:0 auto; - text-align:center; -} - -.docnav li.next a strong { - background: url(../images/stock-go-forward.png) top right no-repeat; - padding-top:3px; - padding-bottom:4px; - padding-right:28px; - font-size:1.2em; -} - -.docnav li.previous a strong { - background: url(../images/stock-go-back.png) top left no-repeat; - padding-top:3px; - padding-bottom:4px; - padding-left:28px; - padding-right:0.5em; - font-size:1.2em; -} - -.docnav li.home a strong { - background: url(../images/stock-home.png) top left no-repeat; - padding:5px; - padding-left:28px; - font-size:1.2em; -} - -.docnav li.up a strong { - background: url(../images/stock-go-up.png) top left no-repeat; - padding:5px; - padding-left:28px; - font-size:1.2em; -} - -.docnav a:link, .docnav a:visited { - color:#666; -} - -.docnav a:hover, .docnav a:focus, .docnav a:active { - color:black; -} - -.docnav a { - max-width: 10em; - overflow:hidden; -} - -.docnav a:link strong { - text-decoration:none; -} - -.docnav { - margin:0 auto; - text-align:center; -} - -ul.docnav { - margin-bottom: 1em; -} -/* Reports */ -.reports ul { - list-style:none; - margin:0em; - padding:0em; -} - -.reports li{ - margin:0em; - padding:0em; -} - -.reports li.odd { - background-color: #eeeeee; - margin:0em; - padding:0em; -} - -.reports dl { - display:inline; - margin:0em; - padding:0em; - float:right; - margin-right: 17em; - margin-top:-1.3em; -} - -.reports dt { - display:inline; - margin:0em; - padding:0em; -} - -.reports dd { - display:inline; - margin:0em; - padding:0em; - padding-right:.5em; -} - -.reports h2, .reports h3{ - display:inline; - padding-right:.5em; - font-size:10pt; - font-weight:normal; -} - -.reports div.progress { - display:inline; - float:right; - width:16em; - background:#c00 url(../images/shine.png) top left repeat-x; - margin:0em; - margin-top:-1.3em; - padding:0em; - border:none; -} - -/*uniform*/ -body.results, body.reports { - max-width:57em ; - padding:0em; -} - -/*Progress Bar*/ -div.progress { - display:block; - float:left; - width:16em; - background:#c00 url(../images/shine.png) top left repeat-x; - height:1em; -} - -div.progress span { - height:1em; - float:left; -} - -div.progress span.translated { - background:#6c3 url(../images/shine.png) top left repeat-x; -} - -div.progress span.fuzzy { - background:#ff9f00 url(../images/shine.png) top left repeat-x; -} - - -/*Results*/ - -.results ul { - list-style:none; - margin:0em; - padding:0em; -} - -.results li{ - margin:0em; - padding:0em; -} - -.results li.odd { - background-color: #eeeeee; - margin:0em; - padding:0em; -} - -.results dl { - display:inline; - margin:0em; - padding:0em; - float:right; - margin-right: 17em; - margin-top:-1.3em; -} - -.results dt { - display:inline; - margin:0em; - padding:0em; -} - -.results dd { - display:inline; - margin:0em; - padding:0em; - padding-right:.5em; -} - -.results h2, .results h3 { - display:inline; - padding-right:.5em; - font-size:10pt; - font-weight:normal; -} - -.results div.progress { - display:inline; - float:right; - width:16em; - background:#c00 url(../images/shine.png) top left repeat-x; - margin:0em; - margin-top:-1.3em; - padding:0em; - border:none; -} - -/* Dirty EVIL Mozilla hack for round corners */ -pre { - -moz-border-radius:11px; - -webkit-border-radius:11px; - border-radius: 11px; - page-break-inside: avoid; -} - -.example { - -moz-border-radius:0px; - -webkit-border-radius:0px; - border-radius: 0px; - page-break-inside: avoid; -} - -.package, .citetitle { - font-style: italic; -} - -.titlepage .edition { - color: #336699; - background-color: transparent; - margin-top: 1em; - margin-bottom: 1em; - font-size: 1.4em; - font-weight: bold; - text-align: center; -} - -span.remark { - background-color: #ff00ff; -} - -.draft { - background-image: url(../images/watermark-draft.png); - background-repeat: repeat-y; - background-position: center; -} - -.foreignphrase { - font-style: inherit; -} - -dt { - clear:both; -} - -dt img { - border-style: none; - max-width: 112px; -} - -dt object { - max-width: 112px; -} - -dt .inlinemediaobject, dt object { - display: inline; - float: left; - margin-bottom: 1em; - padding-right: 1em; - width: 112px; -} - -dl:after { - display: block; - clear: both; - content: ""; -} - -.toc dd { - padding-bottom: 0em; - margin-bottom: 1em; - padding-left: 1.3em; - margin-left: 0em; -} - -div.toc > dl > dt { - padding-bottom: 0em; - margin-bottom: 0em; - margin-top: 1em; -} - - -.strikethrough { - text-decoration: line-through; -} - -.underline { - text-decoration: underline; -} - -.calloutlist img, .callout { - padding: 0em; - margin: 0em; - width: 12pt; - display: inline; - vertical-align: middle; -} - -.stepalternatives { - list-style-image: none; - list-style-type: none; -} - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/css/default.css b/defensive-coding/tmp/en-US/html/Common_Content/css/default.css deleted file mode 100644 index bf38ebb..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/css/default.css +++ /dev/null @@ -1,3 +0,0 @@ -@import url("common.css"); -@import url("overrides.css"); -@import url("lang.css"); diff --git a/defensive-coding/tmp/en-US/html/Common_Content/css/lang.css b/defensive-coding/tmp/en-US/html/Common_Content/css/lang.css deleted file mode 100644 index 81c3115..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/css/lang.css +++ /dev/null @@ -1,2 +0,0 @@ -/* place holder */ - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/css/overrides.css b/defensive-coding/tmp/en-US/html/Common_Content/css/overrides.css deleted file mode 100644 index bd5f3c7..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/css/overrides.css +++ /dev/null @@ -1,47 +0,0 @@ -a:link { - color:#0066cc; -} - -a:visited { - color:#6699cc; -} - -h1 { - color:#a70000; -} - -.producttitle { - background: #a70000 url(../images/h1-bg.png) top left repeat; -} - -.section h1.title { - color:#a70000; -} - -h2,h3,h4,h5,h6 { - color:#a70000; -} - -table { - border:1px solid #aaa; -} - -table th { - background-color:#900; -} - -table tr.even td { - background-color:#f5f5f5; -} - -.revhistory table th { - color:#a70000; -} - -.titlepage .edition { - color: #a70000; -} - -span.remark{ - background-color: #ffff00; -} diff --git a/defensive-coding/tmp/en-US/html/Common_Content/css/print.css b/defensive-coding/tmp/en-US/html/Common_Content/css/print.css deleted file mode 100644 index 773d8ae..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/css/print.css +++ /dev/null @@ -1,16 +0,0 @@ -@import url("common.css"); -@import url("overrides.css"); -@import url("lang.css"); - -#tocframe { - display: none; -} - -body.toc_embeded { - margin-left: 30px; -} - -.producttitle { - color: #336699; -} - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/1.png b/defensive-coding/tmp/en-US/html/Common_Content/images/1.png deleted file mode 100644 index 270707b..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/1.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/1.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/1.svg deleted file mode 100644 index 0a7036e..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/1.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/10.png b/defensive-coding/tmp/en-US/html/Common_Content/images/10.png deleted file mode 100644 index ec548f3..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/10.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/10.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/10.svg deleted file mode 100644 index d1c32c7..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/10.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/11.png b/defensive-coding/tmp/en-US/html/Common_Content/images/11.png deleted file mode 100644 index f59d84b..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/11.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/11.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/11.svg deleted file mode 100644 index 872d14a..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/11.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/12.png b/defensive-coding/tmp/en-US/html/Common_Content/images/12.png deleted file mode 100644 index c8a3906..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/12.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/12.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/12.svg deleted file mode 100644 index 6bc95d2..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/12.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/13.png b/defensive-coding/tmp/en-US/html/Common_Content/images/13.png deleted file mode 100644 index 2db6743..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/13.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/13.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/13.svg deleted file mode 100644 index cf105bc..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/13.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/14.png b/defensive-coding/tmp/en-US/html/Common_Content/images/14.png deleted file mode 100644 index 1a12fb3..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/14.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/14.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/14.svg deleted file mode 100644 index 1009bce..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/14.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/15.png b/defensive-coding/tmp/en-US/html/Common_Content/images/15.png deleted file mode 100644 index 2532d13..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/15.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/15.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/15.svg deleted file mode 100644 index 52daf8d..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/15.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/16.png b/defensive-coding/tmp/en-US/html/Common_Content/images/16.png deleted file mode 100644 index 3b3f17f..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/16.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/16.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/16.svg deleted file mode 100644 index 95dedc2..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/16.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/17.png b/defensive-coding/tmp/en-US/html/Common_Content/images/17.png deleted file mode 100644 index d0f12f7..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/17.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/17.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/17.svg deleted file mode 100644 index 7b3e327..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/17.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/18.png b/defensive-coding/tmp/en-US/html/Common_Content/images/18.png deleted file mode 100644 index ed2f1fe..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/18.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/18.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/18.svg deleted file mode 100644 index fc744d5..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/18.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/19.png b/defensive-coding/tmp/en-US/html/Common_Content/images/19.png deleted file mode 100644 index a145b4a..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/19.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/19.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/19.svg deleted file mode 100644 index 69c6f5f..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/19.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/2.png b/defensive-coding/tmp/en-US/html/Common_Content/images/2.png deleted file mode 100644 index 126f8fd..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/2.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/2.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/2.svg deleted file mode 100644 index 15424b2..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/2.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/20.png b/defensive-coding/tmp/en-US/html/Common_Content/images/20.png deleted file mode 100644 index b23618f..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/20.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/20.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/20.svg deleted file mode 100644 index 7abd11e..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/20.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/21.png b/defensive-coding/tmp/en-US/html/Common_Content/images/21.png deleted file mode 100644 index 91b602b..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/21.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/21.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/21.svg deleted file mode 100644 index 8d33472..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/21.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/22.png b/defensive-coding/tmp/en-US/html/Common_Content/images/22.png deleted file mode 100644 index 33e0374..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/22.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/22.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/22.svg deleted file mode 100644 index 0224965..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/22.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/23.png b/defensive-coding/tmp/en-US/html/Common_Content/images/23.png deleted file mode 100644 index cc961c1..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/23.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/23.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/23.svg deleted file mode 100644 index 72609f4..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/23.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/24.png b/defensive-coding/tmp/en-US/html/Common_Content/images/24.png deleted file mode 100644 index 17b1531..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/24.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/24.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/24.svg deleted file mode 100644 index 5b34c33..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/24.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/25.png b/defensive-coding/tmp/en-US/html/Common_Content/images/25.png deleted file mode 100644 index 193686c..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/25.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/25.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/25.svg deleted file mode 100644 index 4f57373..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/25.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/26.png b/defensive-coding/tmp/en-US/html/Common_Content/images/26.png deleted file mode 100644 index e8bf82a..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/26.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/26.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/26.svg deleted file mode 100644 index aff5a90..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/26.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/27.png b/defensive-coding/tmp/en-US/html/Common_Content/images/27.png deleted file mode 100644 index 06dfc67..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/27.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/27.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/27.svg deleted file mode 100644 index 0769006..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/27.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/28.png b/defensive-coding/tmp/en-US/html/Common_Content/images/28.png deleted file mode 100644 index 065ce1a..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/28.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/28.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/28.svg deleted file mode 100644 index 60cf157..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/28.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/29.png b/defensive-coding/tmp/en-US/html/Common_Content/images/29.png deleted file mode 100644 index 8f28d5b..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/29.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/29.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/29.svg deleted file mode 100644 index 6dc6635..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/29.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/3.png b/defensive-coding/tmp/en-US/html/Common_Content/images/3.png deleted file mode 100644 index 9e3ae40..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/3.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/3.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/3.svg deleted file mode 100644 index 2e88abd..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/3.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/30.png b/defensive-coding/tmp/en-US/html/Common_Content/images/30.png deleted file mode 100644 index d583185..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/30.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/30.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/30.svg deleted file mode 100644 index 717ae1c..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/30.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/31.png b/defensive-coding/tmp/en-US/html/Common_Content/images/31.png deleted file mode 100644 index 9146925..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/31.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/31.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/31.svg deleted file mode 100644 index 25c7b52..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/31.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/32.png b/defensive-coding/tmp/en-US/html/Common_Content/images/32.png deleted file mode 100644 index cbc972e..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/32.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/32.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/32.svg deleted file mode 100644 index 79866e8..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/32.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/33.png b/defensive-coding/tmp/en-US/html/Common_Content/images/33.png deleted file mode 100644 index 7c1ab6a..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/33.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/33.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/33.svg deleted file mode 100644 index 01c3222..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/33.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/34.png b/defensive-coding/tmp/en-US/html/Common_Content/images/34.png deleted file mode 100644 index 2585ddc..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/34.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/34.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/34.svg deleted file mode 100644 index cf9cf7c..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/34.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/35.png b/defensive-coding/tmp/en-US/html/Common_Content/images/35.png deleted file mode 100644 index 86ff09c..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/35.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/35.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/35.svg deleted file mode 100644 index 948ed84..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/35.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/36.png b/defensive-coding/tmp/en-US/html/Common_Content/images/36.png deleted file mode 100644 index c4a7f79..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/36.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/36.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/36.svg deleted file mode 100644 index cff32b5..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/36.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/37.png b/defensive-coding/tmp/en-US/html/Common_Content/images/37.png deleted file mode 100644 index 91cf6ae..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/37.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/37.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/37.svg deleted file mode 100644 index 6694ee4..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/37.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/38.png b/defensive-coding/tmp/en-US/html/Common_Content/images/38.png deleted file mode 100644 index 882f8cd..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/38.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/38.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/38.svg deleted file mode 100644 index 26ded93..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/38.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/39.png b/defensive-coding/tmp/en-US/html/Common_Content/images/39.png deleted file mode 100644 index cc0726d..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/39.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/39.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/39.svg deleted file mode 100644 index 082c1b1..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/39.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/4.png b/defensive-coding/tmp/en-US/html/Common_Content/images/4.png deleted file mode 100644 index 266e714..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/4.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/4.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/4.svg deleted file mode 100644 index 25888e4..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/4.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/40.png b/defensive-coding/tmp/en-US/html/Common_Content/images/40.png deleted file mode 100644 index b92fd2f..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/40.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/40.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/40.svg deleted file mode 100644 index 33ef96a..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/40.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/5.png b/defensive-coding/tmp/en-US/html/Common_Content/images/5.png deleted file mode 100644 index 94153bd..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/5.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/5.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/5.svg deleted file mode 100644 index 7d1dabd..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/5.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/6.png b/defensive-coding/tmp/en-US/html/Common_Content/images/6.png deleted file mode 100644 index 792940e..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/6.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/6.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/6.svg deleted file mode 100644 index 3ab7c39..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/6.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/7.png b/defensive-coding/tmp/en-US/html/Common_Content/images/7.png deleted file mode 100644 index 59eaefd..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/7.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/7.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/7.svg deleted file mode 100644 index ab9cb5d..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/7.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/8.png b/defensive-coding/tmp/en-US/html/Common_Content/images/8.png deleted file mode 100644 index 6aad94b..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/8.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/8.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/8.svg deleted file mode 100644 index 23b1e20..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/8.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/9.png b/defensive-coding/tmp/en-US/html/Common_Content/images/9.png deleted file mode 100644 index 2478355..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/9.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/9.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/9.svg deleted file mode 100644 index 80db11b..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/9.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/bkgrnd_greydots.png b/defensive-coding/tmp/en-US/html/Common_Content/images/bkgrnd_greydots.png deleted file mode 100644 index 2333a6d..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/bkgrnd_greydots.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/bullet_arrowblue.png b/defensive-coding/tmp/en-US/html/Common_Content/images/bullet_arrowblue.png deleted file mode 100644 index c235534..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/bullet_arrowblue.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/documentation.png b/defensive-coding/tmp/en-US/html/Common_Content/images/documentation.png deleted file mode 100644 index 7ae45bd..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/documentation.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/dot.png b/defensive-coding/tmp/en-US/html/Common_Content/images/dot.png deleted file mode 100644 index 36a6859..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/dot.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/dot2.png b/defensive-coding/tmp/en-US/html/Common_Content/images/dot2.png deleted file mode 100644 index 40aff92..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/dot2.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/green.png b/defensive-coding/tmp/en-US/html/Common_Content/images/green.png deleted file mode 100644 index ebb3c24..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/green.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/h1-bg.png b/defensive-coding/tmp/en-US/html/Common_Content/images/h1-bg.png deleted file mode 100644 index 31397b5..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/h1-bg.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/image_left.png b/defensive-coding/tmp/en-US/html/Common_Content/images/image_left.png deleted file mode 100644 index ecd4856..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/image_left.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/image_right.png b/defensive-coding/tmp/en-US/html/Common_Content/images/image_right.png deleted file mode 100644 index 7ae45bd..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/image_right.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/important.png b/defensive-coding/tmp/en-US/html/Common_Content/images/important.png deleted file mode 100644 index eb42966..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/important.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/important.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/important.svg deleted file mode 100644 index 064c783..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/important.svg +++ /dev/null @@ -1,30 +0,0 @@ - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/note.png b/defensive-coding/tmp/en-US/html/Common_Content/images/note.png deleted file mode 100644 index 2b421d2..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/note.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/note.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/note.svg deleted file mode 100644 index abe5a60..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/note.svg +++ /dev/null @@ -1,28 +0,0 @@ - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/red.png b/defensive-coding/tmp/en-US/html/Common_Content/images/red.png deleted file mode 100644 index d32d5e2..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/red.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/redhat-logo.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/redhat-logo.svg deleted file mode 100644 index 1001776..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/redhat-logo.svg +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/rhlogo.png b/defensive-coding/tmp/en-US/html/Common_Content/images/rhlogo.png deleted file mode 100644 index ecd4856..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/rhlogo.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/shade.png b/defensive-coding/tmp/en-US/html/Common_Content/images/shade.png deleted file mode 100644 index a73afdf..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/shade.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/shine.png b/defensive-coding/tmp/en-US/html/Common_Content/images/shine.png deleted file mode 100644 index a18f7c4..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/shine.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-back.png b/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-back.png deleted file mode 100644 index 8160290..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-back.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-forward.png b/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-forward.png deleted file mode 100644 index be86474..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-forward.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-up.png b/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-up.png deleted file mode 100644 index 52a31ed..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-go-up.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-home.png b/defensive-coding/tmp/en-US/html/Common_Content/images/stock-home.png deleted file mode 100644 index b9ce2b8..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/stock-home.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/title_logo.png b/defensive-coding/tmp/en-US/html/Common_Content/images/title_logo.png deleted file mode 100644 index ecd4856..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/title_logo.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/title_logo.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/title_logo.svg deleted file mode 100644 index 1001776..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/title_logo.svg +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/warning.png b/defensive-coding/tmp/en-US/html/Common_Content/images/warning.png deleted file mode 100644 index 3745cf6..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/warning.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/warning.svg b/defensive-coding/tmp/en-US/html/Common_Content/images/warning.svg deleted file mode 100644 index 484138d..0000000 --- a/defensive-coding/tmp/en-US/html/Common_Content/images/warning.svg +++ /dev/null @@ -1,32 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/watermark-draft.png b/defensive-coding/tmp/en-US/html/Common_Content/images/watermark-draft.png deleted file mode 100644 index 0ead5af..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/watermark-draft.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/Common_Content/images/yellow.png b/defensive-coding/tmp/en-US/html/Common_Content/images/yellow.png deleted file mode 100644 index 223865d..0000000 Binary files a/defensive-coding/tmp/en-US/html/Common_Content/images/yellow.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/html/ch01s03s04.html b/defensive-coding/tmp/en-US/html/ch01s03s04.html deleted file mode 100644 index 14dc3a3..0000000 --- a/defensive-coding/tmp/en-US/html/ch01s03s04.html +++ /dev/null @@ -1,12 +0,0 @@ - -1.3.4. Custom memory allocators

Product SiteDocumentation Site

1.3.4. Custom memory allocators

- Custom memory allocates come in two forms: replacements for malloc, and completely different interfaces for memory management. Both approaches can reduce the effectiveness of valgrind and similar tools, and the heap corruption detection provided by GNU libc, so they should be avoided. -
- Memory allocators are difficult to write and contain many performance and security pitfalls. -
  • - When computing array sizes or rounding up allocation requests (to the next allocation granularity, or for alignment purposes), checks for arithmetic overflow are required. -
  • - Size computations for array allocations need overflow checking. See Section 1.3.3, “Array allocation”. -
  • - It can be difficult to beat well-tuned general-purpose allocators. In micro-benchmarks, pool allocators can show huge wins, and size-specific pools can reduce internal fragmentation. But often, utilization of individual pools is poor, and -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch01s03s05.html b/defensive-coding/tmp/en-US/html/ch01s03s05.html deleted file mode 100644 index accb5f0..0000000 --- a/defensive-coding/tmp/en-US/html/ch01s03s05.html +++ /dev/null @@ -1,6 +0,0 @@ - -1.3.5. Conservative garbage collection

Product SiteDocumentation Site

1.3.5. Conservative garbage collection

- Garbage collection can be an alternative to explicit memory management using malloc and free. The Boehm-Dehmers-Weiser allocator can be used from C programs, with minimal type annotations. Performance is competitive with malloc on 64-bit architectures, especially for multi-threaded programs. The stop-the-world pauses may be problematic for some real-time applications, though. -
- However, using a conservative garbage collector may reduce opertunities for code reduce because once one library in a program uses garbage collection, the whole process memory needs to be subject to it, so that no pointers are missed. The Boehm-Dehmers-Weiser collector also reserves certain signals for internal use, so it is not fully transparent to the rest of the program. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch03s02.html b/defensive-coding/tmp/en-US/html/ch03s02.html deleted file mode 100644 index 62c8422..0000000 --- a/defensive-coding/tmp/en-US/html/ch03s02.html +++ /dev/null @@ -1,14 +0,0 @@ - -3.2. Run-time compilation and code generation

Product SiteDocumentation Site

3.2. Run-time compilation and code generation

- The following Python functions and statements related to code execution should be avoided: -
  • - compile -
  • - eval -
  • - exec -
  • - execfile -
- If you need to parse integers or floating point values, use the int and float functions instead of eval. Sandboxing untrusted Python code does not work reliably. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch03s03.html b/defensive-coding/tmp/en-US/html/ch03s03.html deleted file mode 100644 index 5452b7d..0000000 --- a/defensive-coding/tmp/en-US/html/ch03s03.html +++ /dev/null @@ -1,4 +0,0 @@ - -3.3. Sandboxing

Product SiteDocumentation Site

3.3. Sandboxing

- The rexec Python module cannot safely sandbox untrusted code and should not be used. The standard CPython implementation is not suitable for sandboxing. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch04s02.html b/defensive-coding/tmp/en-US/html/ch04s02.html deleted file mode 100644 index 8b9faf7..0000000 --- a/defensive-coding/tmp/en-US/html/ch04s02.html +++ /dev/null @@ -1,6 +0,0 @@ - -4.2. Object orientation

Product SiteDocumentation Site

4.2. Object orientation

- Classes should be either designed as base classes, or it should be impossible to use them as base classes (like final classes in Java). Classes which are not designed for inheritance and are used as base classes nevertheless create potential maintenance hazards because it is difficult to predict how client code will react when calls to virtual methods are added, reordered or removed. -
- Virtual member functions can be used as callbacks. See Section 4.3, “Callbacks” for some of the challenges involved. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch04s04.html b/defensive-coding/tmp/en-US/html/ch04s04.html deleted file mode 100644 index dc8c688..0000000 --- a/defensive-coding/tmp/en-US/html/ch04s04.html +++ /dev/null @@ -1,20 +0,0 @@ - -4.4. Process attributes

Product SiteDocumentation Site

4.4. Process attributes

- Several attributes are global and affect all code in the process, not just the library that manipulates them. -
  • - environment variables (see Section 8.3.1, “Accessing environment variables”) -
  • - umask -
  • - user IDs, group IDs and capabilities -
  • - current working directory -
  • - signal handlers, signal masks and signal delivery -
  • - file locks (especially fcntl locks behave in surprising ways, not just in a multi-threaded environment) -
- Library code should avoid manipulating these global process attributes. It should not rely on environment variables, umask, the current working directory and signal masks because these attributes can be inherted from an untrusted source. -
- In addition, there are obvious process-wide aspects such as the virtual memory layout, the set of open files and dynamic shared objects, but with the exception of shared objects, these can be manipulated in a relatively isolated way. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch07s02.html b/defensive-coding/tmp/en-US/html/ch07s02.html deleted file mode 100644 index 8e45a3e..0000000 --- a/defensive-coding/tmp/en-US/html/ch07s02.html +++ /dev/null @@ -1,10 +0,0 @@ - -7.2. Named temporary files

Product SiteDocumentation Site

7.2. Named temporary files

- The mkostemp function creates a named temporary file. You should specify the O_CLOEXEC flag to avoid file descriptor leaks to subprocesses. (Applications which do not use multiple threads can also use mkstemp, but libraries should use mkostemp.) For determining the directory part of the file name pattern, see Section 7.1, “Obtaining the location of temporary directory”. -
- The file is not removed automatically. It is not safe to rename or delete the file before processing, or transform the name in any way (for example, by adding a file extension). If you need multiple temporary files, call mkostemp multiple times. Do not create additional file names derived from the name provided by a previous mkostemp call. However, it is safe to close the descriptor returned by mkostemp and reopen the file using the generated name. -
- The Python class tempfile.NamedTemporaryFile provides similar functionality, except that the file is deleted automatically by default. Note that you may have to use the file attribute to obtain the actual file object because some programming interfaces cannot deal with file-like objects. The C function mkostemp is also available as tempfile.mkstemp. -
- In Java, you can use the java.io.File.createTempFile(String, String, File) function, using the temporary file location determined according to Section 7.1, “Obtaining the location of temporary directory”. Do not use java.io.File.deleteOnExit() to delete temporary files, and do not register a shutdown hook for each temporary file you create. In both cases, the deletion hint cannot be removed from the system if you delete the temporary file prior to termination of the VM, causing a memory leak. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch07s03.html b/defensive-coding/tmp/en-US/html/ch07s03.html deleted file mode 100644 index 401cd33..0000000 --- a/defensive-coding/tmp/en-US/html/ch07s03.html +++ /dev/null @@ -1,10 +0,0 @@ - -7.3. Temporary files without names

Product SiteDocumentation Site

7.3. Temporary files without names

- The tmpfile function creates a temporary file and immediately deletes it, while keeping the file open. As a result, the file lacks a name and its space is deallocated as soon as the file descriptor is closed (including the implicit close when the process terminates). This avoids cluttering the temporary directory with orphaned files. -
- Alternatively, if the maximum size of the temporary file is known beforehand, the fmemopen function can be used to create a FILE * object which is backed by memory. -
- In Python, unnamed temporary files are provided by the tempfile.TemporaryFile class, and the tempfile.SpooledTemporaryFile class provides a way to avoid creation of small temporary files. -
- Java does not support unnamed temporary files. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch07s05.html b/defensive-coding/tmp/en-US/html/ch07s05.html deleted file mode 100644 index 8966542..0000000 --- a/defensive-coding/tmp/en-US/html/ch07s05.html +++ /dev/null @@ -1,16 +0,0 @@ - -7.5. Compensating for unsafe file creation

Product SiteDocumentation Site

7.5. Compensating for unsafe file creation

- There are two ways to make a function or program which excepts a file name safe for use with temporary files. See Section 8.1, “Safe process creation”, for details on subprocess creation. -
  • - Create a temporary directory and place the file there. If possible, run the program in a subprocess which uses the temporary directory as its current directory, with a restricted environment. Use generated names for all files in that temporary directory. (See Section 7.4, “Temporary directories”.) -
  • - Create the temporary file and pass the generated file name to the function or program. This only works if the function or program can cope with a zero-length existing file. It is safe only under additional assumptions: -
    • - The function or program must not create additional files whose name is derived from the specified file name or are otherwise predictable. -
    • - The function or program must not delete the file before processing it. -
    • - It must not access any existing files in the same directory. -
    - It is often difficult to check whether these additional assumptions are matched, therefore this approach is not recommended. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch08s02.html b/defensive-coding/tmp/en-US/html/ch08s02.html deleted file mode 100644 index 0781cb1..0000000 --- a/defensive-coding/tmp/en-US/html/ch08s02.html +++ /dev/null @@ -1,14 +0,0 @@ - -8.2. Handling child process termination

Product SiteDocumentation Site

8.2. Handling child process termination

- When child processes terminate, the parent process is signalled. A stub of the terminated processes (a zombie, shown as <defunct> by ps) is kept around until the status information is collected (reaped) by the parent process. Over the years, several interfaces for this have been invented: -
  • - The parent process calls wait, waitpid, waitid, wait3 or wait4, without specifying a process ID. This will deliver any matching process ID. This approach is typically used from within event loops. -
  • - The parent process calls waitpid, waitid, or wait4, with a specific process ID. Only data for the specific process ID is returned. This is typically used in code which spawns a single subprocess in a synchronous manner. -
  • - The parent process installs a handler for the SIGCHLD signal, using sigaction, and specifies to the SA_NOCLDWAIT flag. This approach could be used by event loops as well. -
- None of these approaches can be used to wait for child process terminated in a completely thread-safe manner. The parent process might execute an event loop in another thread, which could pick up the termination signal. This means that libraries typically cannot make free use of child processes (for example, to run problematic code with reduced privileges in a separate address space). -
- At the moment, the parent process should explicitly wait for termination of the child process using waitpid or waitpid, and hope that the status is not collected by an event loop first. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch08s03.html b/defensive-coding/tmp/en-US/html/ch08s03.html deleted file mode 100644 index 05b82d8..0000000 --- a/defensive-coding/tmp/en-US/html/ch08s03.html +++ /dev/null @@ -1,34 +0,0 @@ - -8.3. SUID/SGID processes

Product SiteDocumentation Site

8.3. SUID/SGID processes

- Programs can be marked in the file system to indicate to the kernel that a trust transition should happen if the program is run. The SUID file permission bit indicates that an executable should run with the effective user ID equal to the owner of the executable file. Similarly, with the SGID bit, the effective group ID is set to the group of the executable file. -
- Linux supports fscaps, which can grant additional capabilities to a process in a finer-grained manner. Additional mechanisms can be provided by loadable security modules. -
- When such a trust transition has happened, the process runs in a potentially hostile environment. Additional care is necessary not to rely on any untrusted information. These concerns also apply to libraries which can be linked into such processes. -

8.3.1. Accessing environment variables

- The following steps are required so that a program does not accidentally pick up untrusted data from environment variables. -
  • - Compile your C/C++ sources with -D_GNU_SOURCE. The Autoconf macro AC_GNU_SOURCE ensures this. -
  • - Check for the presence of the secure_getenv and __secure_getenv function. The Autoconf directive AC_CHECK_FUNCS([__secure_getenv secure_getenv]) performs these checks. -
  • - Arrange for a proper definition of the secure_getenv function. See Example 8.1, “Obtaining a definition for secure_getenv”. -
  • - Use secure_getenv instead of getenv to obtain the value of critical environment variables. secure_getenv will pretend the variable has not bee set if the process environment is not trusted. -
- Critical environment variables are debugging flags, configuration file locations, plug-in and log file locations, and anything else that might be used to bypass security restrictions or cause a privileged process to behave in an unexpected way. -
- Either the secure_getenv function or the __secure_getenv is available from GNU libc. -
Example 8.1. Obtaining a definition for secure_getenv
-
-#include <stdlib.h>
-
-#ifndef HAVE_SECURE_GETENV
-#  ifdef HAVE__SECURE_GETENV
-#    define secure_getenv __secure_getenv
-#  else
-#    error neither secure_getenv nor __secure_getenv are available
-#  endif
-#endif
-
-

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch08s05.html b/defensive-coding/tmp/en-US/html/ch08s05.html deleted file mode 100644 index 2cfd640..0000000 --- a/defensive-coding/tmp/en-US/html/ch08s05.html +++ /dev/null @@ -1,8 +0,0 @@ - -8.5. Semantics of command line arguments

Product SiteDocumentation Site

8.5. Semantics of command line arguments

- After process creation and option processing, it is up to the child process to interpret the arguments. Arguments can be file names, host names, or URLs, and many other things. URLs can refer to the local network, some server on the Internet, or to the local file system. Some applications even accept arbitrary code in arguments (for example, python with the -c option). -
- Similar concerns apply to environment variables, the contents of the current directory and its subdirectories. -
- Consequently, careful analysis is required if it is safe to pass untrusted data to another program. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch09s02.html b/defensive-coding/tmp/en-US/html/ch09s02.html deleted file mode 100644 index d5aa39b..0000000 --- a/defensive-coding/tmp/en-US/html/ch09s02.html +++ /dev/null @@ -1,4 +0,0 @@ - -9.2. Protocol design

Product SiteDocumentation Site

9.2. Protocol design

- Binary formats with explicit length fields are more difficult to parse robustly than those where the length of dynamically-sized elements is derived from sentinel values. A protocol which does not use length fields and can be written in printable ASCII characters simplifies testing and debugging. However, binary protocols with length fields may be more efficient to parse. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch09s03.html b/defensive-coding/tmp/en-US/html/ch09s03.html deleted file mode 100644 index c2b359e..0000000 --- a/defensive-coding/tmp/en-US/html/ch09s03.html +++ /dev/null @@ -1,20 +0,0 @@ - -9.3. Library support for deserialization

Product SiteDocumentation Site

9.3. Library support for deserialization

- For some languages, generic libraries are available which allow to serialize and deserialize user-defined objects. The deserialization part comes in one of two flavors, depending on the library. The first kind uses type information in the data stream to control which objects are instantiated. The second kind uses type definitions supplied by the programmer. The first one allows arbitrary object instantiation, the second one generally does not. -
- The following serialization frameworks are in the first category, are known to be unsafe, and must not be used for untrusted data: -
  • - Python's pickle and cPickle modules -
  • - Perl's Storable package -
  • - Java serialization (java.io.ObjectInputStream) -
  • - PHP serialization (unserialize) -
  • - Most implementations of YAML -
- When using a type-directed deserialization format where the types of the deserialized objects are specified by the programmer, make sure that the objects which can be instantiated cannot perform any destructive actions in their destructors, even when the data members have been manipulated. -
- JSON decoders do not suffer from this problem. But you must not use the eval function to parse JSON objects in Javascript; even with the regular expression filter from RFC 4627, there are still information leaks remaining. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch09s05.html b/defensive-coding/tmp/en-US/html/ch09s05.html deleted file mode 100644 index a80e585..0000000 --- a/defensive-coding/tmp/en-US/html/ch09s05.html +++ /dev/null @@ -1,8 +0,0 @@ - -9.5. Protocol Encoders

Product SiteDocumentation Site

9.5. Protocol Encoders

- For protocol encoders, you should write bytes to a buffer which grows as needed, using an exponential sizing policy. Explicit lengths can be patched in later, once they are known. Allocating the required number of bytes upfront typically requires separate code to compute the final size, which must be kept in sync with the actual encoding step, or vulnerabilities may result. In multi-threaded code, parts of the object being deserialized might change, so that the computed size is out of date. -
- You should avoid copying data directly from a received packet during encoding, disregarding the format. Propagating malformed data could enable attacks on other recipients of that data. -
- When using C or C++ and copying whole data structures directly into the output, make sure that you do not leak information in padding bytes between fields or at the end of the struct. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/ch10s02.html b/defensive-coding/tmp/en-US/html/ch10s02.html deleted file mode 100644 index 91b3c8f..0000000 --- a/defensive-coding/tmp/en-US/html/ch10s02.html +++ /dev/null @@ -1,24 +0,0 @@ - -10.2. Randomness

Product SiteDocumentation Site

10.2. Randomness

- The following facilities can be used to generate unpredictable and non-repeating values. When these functions are used without special safeguards, each individual rnadom value should be at least 12 bytes long. -
  • - PK11_GenerateRandom in the NSS library (usable for high data rates) -
  • - RAND_bytes in the OpenSSL library (usable for high data rates) -
  • - gnutls_rnd in GNUTLS, with GNUTLS_RND_RANDOM as the first argument (usable for high data rates) -
  • - java.security.SecureRandom in Java (usable for high data rates) -
  • - os.urandom in Python -
  • - Reading from the /dev/urandom character device -
- All these functions should be non-blocking, and they should not wait until physical randomness becomes available. (Some cryptography providers for Java can cause java.security.SecureRandom to block, however.) Those functions which do not obtain all bits directly from /dev/urandom are suitable for high data rates because they do not deplete the system-wide entropy pool. -

Difficult to use API

- Both RAND_bytes and PK11_GenerateRandom have three-state return values (with conflicting meanings). Careful error checking is required. Please review the documentation when using these functions. -
- Other sources of randomness should be considered predictable. -
- Generating randomness for cryptographic keys in long-term use may need different steps and is best left to cryptographic libraries. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Authentication.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Authentication.html deleted file mode 100644 index 0b6019c..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Authentication.html +++ /dev/null @@ -1,16 +0,0 @@ - -Chapter 11. Authentication and Authorization

Product SiteDocumentation Site

Chapter 11. Authentication and Authorization

11.1. Authenticating servers
11.2. Host-based authentication
11.3. UNIX domain socket authentication
11.4. AF_NETLINK authentication of origin

11.1. Authenticating servers

- When connecting to a server, a client has to make sure that it is actually talking to the server it expects. There are two different aspects, securing the network path, and making sure that the expected user runs the process on the target host. There are several ways to ensure that: -
  • - The server uses a TLS certificate which is valid according to the web browser public key infrastructure, and the client verifies the certificate and the host name. -
  • - The server uses a TLS certificate which is expectedby the client (perhaps it is stored in a configuration file read by the client). In this case, no host name checking is required. -
  • - On Linux, UNIX domain sockets (of the PF_UNIX protocol family, sometimes called PF_LOCAL) are restricted by file system permissions. If the server socket path is not world-writable, the server identity cannot be spoofed by local users. -
  • - Port numbers less than 1024 (trusted ports) can only be used by root, so if a UDP or TCP server is running on the local host and it uses a trusted port, its identity is assured. (Not all operating systems enforce the trusted ports concept, and the network might not be trusted, so it is only useful on the local system.) -
- TLS (Chapter 12, Transport Layer Security) is the recommended way for securing connections over untrusted networks. -
- If the server port number is 1024 is higher, a local user can impersonate the process by binding to this socket, perhaps after crashing the real server by exploiting a denial-of-service vulnerability. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-C.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-C.html deleted file mode 100644 index 42c5195..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-C.html +++ /dev/null @@ -1,105 +0,0 @@ - -Chapter 1. The C Programming Language

Product SiteDocumentation Site

Chapter 1. The C Programming Language

1.1. The core language
1.1.1. Undefined behavior
1.1.2. Recommendations for pointers and array handling
1.1.3. Recommendations for integer arithmetic
1.2. The C standard library
1.2.1. Absolutely banned interfaces
1.2.2. Functions to avoid
1.2.3. String Functions With Explicit Length Arguments
1.3. Memory allocators
1.3.1. malloc and related functions
1.3.2. alloca and other forms of stack-based allocation
1.3.3. Array allocation
1.3.4. Custom memory allocators
1.3.5. Conservative garbage collection

1.1. The core language

- C provides no memory safety. Most recommendations in this section deal with this aspect of the language. -

1.1.1. Undefined behavior

- Some C constructs are defined to be undefined by the C standard. This does not only mean that the standard does not describe what happens when the construct is executed. It also allows optimizing compilers such as GCC to assume that this particular construct is never reached. In some cases, this has caused GCC to optimize security checks away. (This is not a flaw in GCC or the C language. But C certainly has some areas which are more difficult to use than others.) -
- Common sources of undefined behavior are: -
  • - out-of-bounds array accesses -
  • - null pointer dereferences -
  • - overflow in signed integer arithmetic -

1.1.2. Recommendations for pointers and array handling

- Always keep track of the size of the array you are working with. Often, code is more obviously correct when you keep a pointer past the last element of the array, and calculate the number of remaining elements by substracting the current position from that pointer. The alternative, updating a separate variable every time when the position is advanced, is usually less obviously correct. -
- Example 1.1, “Array processing in C” shows how to extract Pascal-style strings from a character buffer. The two pointers kept for length checks are inend and outend. inp and outp are the respective positions. The number of input bytes is checked using the expression len > (size_t)(inend - inp). The cast silences a compiler warning; inend is always larger than inp. -
Example 1.1. Array processing in C
-ssize_t
-extract_strings(const char *in, size_t inlen, char **out, size_t outlen)
-{
-  const char *inp = in;
-  const char *inend = in + inlen;
-  char **outp = out;
-  char **outend = out + outlen;
-
-  while (inp != inend) {
-    size_t len;
-    char *s;
-    if (outp == outend) {
-      errno = ENOSPC;
-      goto err;
-    }
-    len = (unsigned char)*inp;
-    ++inp;
-    if (len > (size_t)(inend - inp)) {
-      errno = EINVAL;
-      goto err;
-    }
-    s = malloc(len + 1);
-    if (s == NULL) {
-      goto err;
-    }
-    memcpy(s, inp, len);
-    inp += len;
-    s[len] = '\0';
-    *outp = s;
-    ++outp;
-  }
-  return outp - out;
-err:
-  {
-    int errno_old = errno;
-    while (out != outp) {
-      free(*out);
-      ++out;
-    }
-    errno = errno_old;
-  }
-  return -1;
-}
-

- It is important that the length checks always have the form len > (size_t)(inend - inp), where len is a variable of type size_t which denotes the total number of bytes which are about to be read or written next. In general, it is not safe to fold multiple such checks into one, as in len1 + len2 > (size_t)(inend - inp), because the expression on the left can overflow or wrap around (see Section 1.1.3, “Recommendations for integer arithmetic”), and it no longer reflects the number of bytes to be processed. -

1.1.3. Recommendations for integer arithmetic

- Overflow in signed integer arithmetic is undefined. This means that it is not possible to check for overflow after it happened, see Example 1.2, “Incorrect overflow detection in C”. -
Example 1.2. Incorrect overflow detection in C
-void report_overflow(void);
-
-int
-add(int a, int b)
-{
-  int result = a + b;
-  if (a < 0 || b < 0) {
-    return -1;
-  }
-  // The compiler can optimize away the following if statement.
-  if (result < 0) {
-    report_overflow();
-  }
-  return result;
-}
-

- The following approaches can be used to check for overflow, without actually causing it. -
  • - Use a wider type to perform the calculation, check that the result is within bounds, and convert the result to the original type. All intermediate results must be checked in this way. -
  • - Perform the calculation in the corresponding unsigned type and use bit fiddling to detect the overflow. -
  • - Compute bounds for acceptable input values which are known to avoid overflow, and reject other values. This is the preferred way for overflow checking on multiplications, see Example 1.3, “Overflow checking for unsigned multiplication”. -
Example 1.3. Overflow checking for unsigned multiplication
-unsigned
-mul(unsigned a, unsigned b)
-{
-  if (b && a > ((unsigned)-1) / b) {
-    report_overflow();
-  }
-  return a * b;
-}
-

- Basic arithmetic operations a commutative, so for bounds checks, there are two different but mathematically equivalent expressions. Sometimes, one of the expressions results in better code because parts of it can be reduced to a constant. This applies to overflow checks for multiplication a * b involving a constant a, where the expression is reduced to b > C for some constant C determined at compile time. The other expression, b && a > ((unsigned)-1) / b, is more difficult to optimize at compile time. -
- When a value is converted to a signed integer, GCC always chooses the result based on 2's complement arithmetic. This GCC extension (which is also implemented by other compilers) helps a lot when implementing overflow checks. -
- Legacy code should be compiled with the -fwrapv GCC option. As a result, GCC will provide 2's complement semantics for integer arithmetic, including defined behavior on integer overflow. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-CXX.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-CXX.html deleted file mode 100644 index bc7ca5a..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-CXX.html +++ /dev/null @@ -1,48 +0,0 @@ - -Chapter 2. The C++ Programming Language

Product SiteDocumentation Site

Chapter 2. The C++ Programming Language

2.1. The core language
2.1.1. Array allocation with operator new[]
2.1.2. Overloading
2.1.3. ABI compatibility and preparing for security updates
2.1.4. C++0X and C++11 support
2.2. The C++ standard library
2.2.1. Containers and operator[]

2.1. The core language

- C++ includes a large subset of the C language. As far as the C subset is used, the recommendations in Chapter 1, The C Programming Language apply. -

2.1.1. Array allocation with operator new[]

- For very large values of n, an expression like new T[n] can return a pointer to a heap region which is too small. In other words, not all array elements are actually backed with heap memory reserved to the array. Current GCC versions generate code that performs a computation of the form sizeof(T) * size_t(n) + cookie_size, where cookie_size is currently at most 8. This computation can overflow, and GCC-generated code does not detect this. -
- The std::vector template can be used instead an explicit array allocation. (The GCC implementation detects overflow internally.) -
- If there is no alternative to operator new[], code which allocates arrays with a variable length must check for overflow manually. For the new T[n] example, the size check could be n || (n > 0 && n > (size_t(-1) - 8) / sizeof(T)). (See Section 1.1.3, “Recommendations for integer arithmetic”.) If there are additional dimensions (which must be constants according to the C++ standard), these should be included as factors in the divisor. -
- These countermeasures prevent out-of-bounds writes and potential code execution. Very large memory allocations can still lead to a denial of service. Section 9.1, “Recommendations for manually written decoders” contains suggestions for mitigating this problem when processing untrusted data. -
- See Section 1.3.3, “Array allocation” for array allocation advice for C-style memory allocation. -

2.1.2. Overloading

- Do not overload functions with versions that have different security characteristics. For instance, do not implement a function strcat which works on std::string arguments. Similarly, do not name methods after such functions. -

2.1.3. ABI compatibility and preparing for security updates

- A stable binary interface (ABI) is vastly preferred for security updates. Without a stable ABI, all reverse dependencies need recompiling, which can be a lot of work and could even be impossible in some cases. Ideally, a security update only updates a single dynamic shared object, and is picked up automatically after restarting affected processes. -
- Outside of extremely performance-critical code, you should ensure that a wide range of changes is possible without breaking ABI. Some very basic guidelines are: -
  • - Avoid inline functions. -
  • - Use the pointer-to-implementation idiom. -
  • - Try to avoid templates. Use them if the increased type safety provides a benefit to the programmer. -
  • - Move security-critical code out of templated code, so that it can be patched in a central place if necessary. -
- The KDE project publishes a document with more extensive guidelines on ABI-preserving changes to C++ code, Policies/Binary Compatibility Issues With C++ (d-pointer refers to the pointer-to-implementation idiom). -

2.1.4. C++0X and C++11 support

- GCC offers different language compatibility modes: -
  • - -std=c++98 for the original 1998 C++ standard -
  • - -std=c++03 for the 1998 standard with the changes from the TR1 technical report -
  • - -std=c++11 for the 2011 C++ standard. This option should not be used. -
  • - -std=c++0x for several different versions of C++11 support in development, depending on the GCC version. This option should not be used. -
- For each of these flags, there are variants which also enable GNU extensions (mostly language features also found in C99 or C11): -std=gnu++98, -std=gnu++03, -std=gnu++11. Again, -std=gnu++11 should not be used. -
- If you enable C++11 support, the ABI of the standard C++ library libstdc++ will change in subtle ways. Currently, no C++ libraries are compiled in C++11 mode, so if you compile your code in C++11 mode, it will be incompatible with the rest of the system. Unfortunately, this is also the case if you do not use any C++11 features. Currently, there is no safe way to enable C++11 mode (except for freestanding applications). -
- The meaning of C++0X mode changed from GCC release to GCC release. Earlier versions were still ABI-compatible with C++98 mode, but in the most recent versions, switching to C++0X mode activates C++11 support, with its compatibility problems. -
- Some C++11 features (or approximations thereof) are available with TR1 support, that is, with -std=c++03 or -std=gnu++03 and in the <tr1/*> header files. This includes std::tr1::shared_ptr (from <tr1/memory>) and std::tr1::function (from <tr1/functional>). For other C++11 features, the Boost C++ library contains replacements. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Python.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Python.html deleted file mode 100644 index d8d3d9c..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Python.html +++ /dev/null @@ -1,16 +0,0 @@ - -Chapter 3. The Python Programming Language

Product SiteDocumentation Site

Chapter 3. The Python Programming Language

3.1. Dangerous standard library features
3.2. Run-time compilation and code generation
3.3. Sandboxing
- Python provides memory safety by default, so low-level security vulnerabilities are rare and typically needs fixing the Python interpreter or standard library itself. -
- Other sections with Python-specific advice include: -

3.1. Dangerous standard library features

- Some areas of the standard library, notably the ctypes module, do not provide memory safety guarantees comparable to the rest of Python. If such functionality is used, the advice in Section 1.1, “The core language” should be followed. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-TLS.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-TLS.html deleted file mode 100644 index 0cccaf4..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-TLS.html +++ /dev/null @@ -1,99 +0,0 @@ - -Chapter 12. Transport Layer Security

Product SiteDocumentation Site

Chapter 12. Transport Layer Security

12.1. Common Pitfalls
12.1.1. OpenSSL Pitfalls
12.1.2. GNUTLS Pitfalls
12.1.3. OpenJDK Pitfalls
12.1.4. NSS Pitfalls
12.2. TLS Clients
12.2.1. Implementation TLS Clients With OpenSSL
12.2.2. Implementation TLS Clients With GNUTLS
12.2.3. Implementing TLS Clients With OpenJDK
12.2.4. Implementing TLS Clients With NSS
12.2.5. Implementing TLS Clients With Python
- Transport Layer Security (TLS, formerly Secure Sockets Layer/SSL) is the recommended way to to protect integrity and confidentiality while data is transferred over an untrusted network connection, and to identify the endpoint. -

12.1. Common Pitfalls

- TLS implementations are difficult to use, and most of them lack a clean API design. The following sections contain implementation-specific advice, and some generic pitfalls are mentioned below. -
  • - Most TLS implementations have questionable default TLS cipher suites. Most of them enable anonymous Diffie-Hellman key exchange (but we generally want servers to authenticate themselves). Many do not disable ciphers which are subject to brute-force attacks because of restricted key lengths. Some even disable all variants of AES in the default configuration. -
    - When overriding the cipher suite defaults, it is recommended to disable all cipher suites which are not present on a whitelist, instead of simply enabling a list of cipher suites. This way, if an algorithm is disabled by default in the TLS implementation in a future security update, the application will not re-enable it. -
  • - The name which is used in certificate validation must match the name provided by the user or configuration file. No host name canonicalization or IP address lookup must be performed. -
  • - The TLS handshake has very poor performance if the TCP Nagle algorithm is active. You should switch on the TCP_NODELAY socket option (at least for the duration of the handshake), or use the Linux-specific TCP_CORK option. -
    Example 12.1. Deactivating the TCP Nagle algorithm
    -const int val = 1;
-int ret = setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &val, sizeof(val));
-if (ret < 0) {
-  perror("setsockopt(TCP_NODELAY)");
-  exit(1);
-}
-

  • - Implementing proper session resumption decreases handshake overhead considerably. This is important if the upper-layer protocol uses short-lived connections (like most application of HTTPS). -
  • - Both client and server should work towards an orderly connection shutdown, that is send close_notify alerts and respond to them. This is especially important if the upper-layer protocol does not provide means to detect connection truncation (like some uses of HTTP). -
  • - When implementing a server using event-driven programming, it is important to handle the TLS handshake properly because it includes multiple network round-trips which can block when an ordinary TCP accept would not. Otherwise, a client which fails to complete the TLS handshake for some reason will prevent the server from handling input from other clients. -
  • - Unlike regular file descriptors, TLS connections cannot be passed between processes. Some TLS implementations add additional restrictions, and TLS connections generally cannot be used across fork function calls (see Section 8.6, “fork as a primitive for parallelism”). -

12.1.1. OpenSSL Pitfalls

- Some OpenSSL function use tri-state return values. Correct error checking is extremely important. Several functions return int values with the following meaning: -
  • - The value 1 indicates success (for example, a successful signature verification). -
  • - The value 0 indicates semantic failure (for example, a signature verification which was unsuccessful because the signing certificate was self-signed). -
  • - The value -1 indicates a low-level error in the system, such as failure to allocate memory using malloc. -
- Treating such tri-state return values as booleans can lead to security vulnerabilities. Note that some OpenSSL functions return boolean results or yet another set of status indicators. Each function needs to be checked individually. -
- Recovering precise error information is difficult. Example 12.2, “Obtaining OpenSSL error codes” shows how to obtain a more precise error code after a function call on an SSL object has failed. However, there are still cases where no detailed error information is available (e.g., if SSL_shutdown fails due to a connection teardown by the other end). -
Example 12.2. Obtaining OpenSSL error codes
-static void __attribute__((noreturn))
-ssl_print_error_and_exit(SSL *ssl, const char *op, int ret)
-{
-  int subcode = SSL_get_error(ssl, ret);
-  switch (subcode) {
-  case SSL_ERROR_NONE:
-    fprintf(stderr, "error: %s: no error to report\n", op);
-    break;
-  case SSL_ERROR_WANT_READ:
-  case SSL_ERROR_WANT_WRITE:
-  case SSL_ERROR_WANT_X509_LOOKUP:
-  case SSL_ERROR_WANT_CONNECT:
-  case SSL_ERROR_WANT_ACCEPT:
-    fprintf(stderr, "error: %s: invalid blocking state %d\n", op, subcode);
-    break;
-  case SSL_ERROR_SSL:
-    fprintf(stderr, "error: %s: TLS layer problem\n", op);
-  case SSL_ERROR_SYSCALL:
-    fprintf(stderr, "error: %s: system call failed: %s\n", op, strerror(errno));
-    break;
-  case SSL_ERROR_ZERO_RETURN:
-    fprintf(stderr, "error: %s: zero return\n", op);
-  }
-  exit(1);
-}
-

- The OPENSSL_config function is documented to never fail. In reality, it can terminate the entire process if there is a failure accessing the configuration file. An error message is written to standard error, but which might not be visible if the function is called from a daemon process. -
- OpenSSL contains two separate ASN.1 DER decoders. One set of decoders operate on BIO handles (the input/output stream abstraction provided by OpenSSL); their decoder function names start with d2i_ and end in _fp or _bio (e.g., d2i_X509_fp or d2i_X509_bio). These decoders must not be used for parsing data from untrusted sources; instead, the variants without the _fp and _bio (e.g., d2i_X509) shall be used. The BIO variants have received considerably less testing and are not very robust. -
- For the same reason, the OpenSSL command line tools (such as openssl x509) are generally generally less robust than the actual library code. They use the BIO functions internally, and not the more robust variants. -
- The command line tools do not always indicate failure in the exit status of the openssl process. For instance, a verification failure in openssl verify result in an exit status of zero. -
- The OpenSSL server and client applications (openssl s_client and openssl s_server) are debugging tools and should never be used as generic clients. For instance, the s_client tool reacts in a surprisign way to lines starting with R and Q. -
- OpenSSL allows application code to access private key material over documented interfaces. This can significantly increase the part of the code base which has to undergo security certification. -

12.1.2. GNUTLS Pitfalls

- libgnutls.so.26 links to libpthread.so.0. Loading the threading library too late causes problems, so the main program should be linked with -lpthread as well. As a result, it can be difficult to use GNUTLS in a plugin which is loaded with the dlopen function. Another side effect is that applications which merely link against GNUTLS (even without actually using it) may incur a substantial overhead because other libraries automatically switch to thread-safe algorithms. -
- The gnutls_global_init function must be called before using any functionality provided by the library. This function is not thread-safe, so external locking is required, but it is not clear which lock should be used. Omitting the synchronization does not just lead to a memory leak, as it is suggested in the GNUTLS documentation, but to undefined behavior because there is no barrier that would enforce memory ordering. -
- The gnutls_global_deinit function does not actually deallocate all resources allocated by gnutls_global_init. It is currently not thread-safe. Therefore, it is best to avoid calling it altogether. -
- The X.509 implementation in GNUTLS is rather lenient. For example, it is possible to create and process X.509 version 1 certificates which carry extensions. These certificates are (correctly) rejected by other implementations. -

12.1.3. OpenJDK Pitfalls

- The Java cryptographic framework is highly modular. As a result, when you request an object implementing some cryptographic functionality, you cannot be completely sure that you end up with the well-tested, reviewed implementation in OpenJDK. -
- OpenJDK (in the source code as published by Oracle) and other implementations of the Java platform require that the system administrator has installed so-called unlimited strength jurisdiction policy files. Without this step, it is not possible to use the secure algorithms which offer sufficient cryptographic strength. Most downstream redistributors of OpenJDK remove this requirement. -
- Some versions of OpenJDK use /dev/random as the randomness source for nonces and other random data which is needed for TLS operation, but does not actually require physical randomness. As a result, TLS applications can block, waiting for more bits to become available in /dev/random. -

12.1.4. NSS Pitfalls

- NSS was not designed to be used by other libraries which can be linked into applications without modifying them. There is a lot of global state. There does not seem to be a way to perform required NSS initialization without race conditions. -
- If the NSPR descriptor is in an unexpected state, the SSL_ForceHandshake function can succeed, but no TLS handshake takes place, the peer is not authenticated, and subsequent data is exchanged in the clear. -
- NSS disables itself if it detects that the process underwent a fork after the library has been initialized. This behavior is required by the PKCS#11 API specification. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Cryptography.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Cryptography.html deleted file mode 100644 index 9136d8f..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Cryptography.html +++ /dev/null @@ -1,32 +0,0 @@ - -Chapter 10. Cryptography

Product SiteDocumentation Site

Chapter 10. Cryptography

10.1. Primitives
10.2. Randomness

10.1. Primitives

- Chosing from the following cryptographic primitives is recommended: -
  • - RSA with 2048 bit keys and OAEP -
  • - AES-128 in CBC mode -
  • - SHA-256 -
  • - HMAC-SHA-256 -
  • - HMAC-SHA-1 -
- Other cryptographic algorithms can be used if they are required for interoperability with existing software: -
  • - RSA with key sizes larger than 1024 and legacy padding -
  • - AES-192 -
  • - AES-256 -
  • - 3DES (triple DES, with two or three 56 bit keys) -
  • - RC4 (but very, very strongly discouraged) -
  • - SHA-1 -
  • - HMAC-MD5 -

Important

- These primitives are difficult to use in a secure way. Custom implementation of security protocols should be avoided. For protecting confidentiality and integrity of network transmissions, TLS should be used (Chapter 12, Transport Layer Security). -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-File_System.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-File_System.html deleted file mode 100644 index b1468c4..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-File_System.html +++ /dev/null @@ -1,34 +0,0 @@ - -Chapter 6. File system manipulation

Product SiteDocumentation Site

Chapter 6. File system manipulation

6.1. Working with files and directories owned by other users
6.2. Accessing the file system as a different user
6.3. File system limits
6.4. File system features
6.5. Checking free space
- In this chapter, we discuss general file system manipulation, with a focus on access files and directories to which an other, potentially untrusted user has write access. -
- Temporary files are covered in their own chapter, Chapter 7, Temporary files. -

6.1. Working with files and directories owned by other users

- Sometimes, it is necessary to operate on files and directories owned by other (potentially untrusted) users. For example, a system administrator could remove the home directory of a user, or a package manager could update a file in a directory which is owned by an application-specific user. This differs from accessing the file system as a specific user; see Section 6.2, “Accessing the file system as a different user”. -
- Accessing files across trust boundaries faces several challenges, particularly if an entire directory tree is being traversed: -
  1. - Another user might add file names to a writable directory at any time. This can interfere with file creation and the order of names returned by readdir. -
  2. - Merely opening and closing a file can have side effects. For instance, an automounter can be triggered, or a tape device rewound. Opening a file on a local file system can block indefinitely, due to mandatory file locking, unless the O_NONBLOCK flag is specified. -
  3. - Hard links and symbolic links can redirect the effect of file system operations in unexpected ways. The O_NOFOLLOW and AT_SYMLINK_NOFOLLOW variants of system calls only affected final path name component. -
  4. - The structure of a directory tree can change. For example, the parent directory of what used to be a subdirectory within the directory tree being processed could suddenly point outside that directory tree. -
- Files should always be created with the O_CREAT and O_EXCL flags, so that creating the file will fail if it already exists. This guards against the unexpected appearance of file names, either due to creation of a new file, or hard-linking of an existing file. In multi-threaded programs, rather than manipulating the umask, create the files with mode 000 if possible, and adjust it afterwards with fchmod. -
- To avoid issues related to symbolic links and directory tree restructuring, the “at” variants of system calls have to be used (that is, functions like openat, fchownat, fchmodat, and unlinkat, together with O_NOFOLLOW or AT_SYMLINK_NOFOLLOW). Path names passed to these functions must have just a single component (that is, without a slash). When descending, the descriptors of parent directories must be kept open. The missing opendirat function can be emulated with openat (with an O_DIRECTORY flag, to avoid opening special files with side effects), followed by fdopendir. -
- If the “at” functions are not available, it is possible to emulate them by changing the current directory. (Obviously, this only works if the process is not multi-threaded.) fchdir has to be used to change the current directory, and the descriptors of the parent directories have to be kept open, just as with the “at”-based approach. chdir("...") is unsafe because it might ascend outside the intended directory tree. -
- This “at” function emulation is currently required when manipulating extended attributes. In this case, the lsetxattr function can be used, with a relative path name consisting of a single component. This also applies to SELinux contexts and the lsetfilecon function. -
- Currently, it is not possible to avoid opening special files and changes to files with hard links if the directory containing them is owned by an untrusted user. (Device nodes can be hard-linked, just as regular files.) fchmodat and fchownat affect files whose link count is greater than one. But opening the files, checking that the link count is one with fstat, and using fchmod and fchown on the file descriptor may have unwanted side effects, due to item 2 above. When creating directories, it is therefore important to change the ownership and permissions only after it has been fully created. Until that point, file names are stable, and no files with unexpected hard links can be introduced. -
- Similarly, when just reading a directory owned by an untrusted user, it is currently impossible to reliably avoid opening special files. -
- There is no workaround against the instability of the file list returned by readdir. Concurrent modification of the directory can result in a list of files being returned which never actually existed on disk. -
- Hard links and symbolic links can be safely deleted using unlinkat without further checks because deletion only affects the name within the directory tree being processed. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Library_Design.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Library_Design.html deleted file mode 100644 index f4573fe..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Library_Design.html +++ /dev/null @@ -1,22 +0,0 @@ - -Chapter 4. Library Design

Product SiteDocumentation Site

Chapter 4. Library Design

4.1. State management
4.1.1. Global state
4.1.2. Handles
4.2. Object orientation
4.3. Callbacks
4.4. Process attributes
- Throught this section, the term client code refers to applications and other libraries using the library. -

4.1. State management

- -

4.1.1. Global state

- Global state should be avoided. -
- If this is impossible, the global state must be protected with a lock. For C/C++, you can use the pthread_mutex_lock and pthread_mutex_unlock functions without linking against -lpthread because the system provides stubs for non-threaded processes. -
- For compatibility with fork, these locks should be acquired and released in helpers registered with pthread_atfork. This function is not available without -lpthread, so you need to use dlsym or a weak symbol to obtain its address. -
- If you need fork protection for other reasons, you should store the process ID and compare it to the value returned by getpid each time you access the global state. (getpid is not implemented as a system call and is fast.) If the value changes, you know that you have to re-create the state object. (This needs to be combined with locking, of course.) -

4.1.2. Handles

- Library state should be kept behind a curtain. Client code should receive only a handle. In C, the handle can be a pointer to an incomplete struct. In C++, the handle can be a pointer to an abstract base class, or it can be hidden using the pointer-to-implementation idiom. -
- The library should provide functions for creating and destroying handles. (In C++, it is possible to use virtual destructors for the latter.) Consistency between creation and destruction of handles is strongly recommended: If the client code created a handle, it is the responsibility of the client code to destroy it. (This is not always possible or convenient, so sometimes, a transfer of ownership has to happen.) -
- Using handles ensures that it is possible to change the way the library represents state in a way that is transparent to client code. This is important to facilitate security updates and many other code changes. -
- It is not always necessary to protect state behind a handle with a lock. This depends on the level of thread safety the library provides. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Serialization.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Serialization.html deleted file mode 100644 index 3a60d65..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Serialization.html +++ /dev/null @@ -1,8 +0,0 @@ - -Chapter 9. Serialization and Deserialization

Product SiteDocumentation Site

Chapter 9. Serialization and Deserialization

9.1. Recommendations for manually written decoders
9.2. Protocol design
9.3. Library support for deserialization
9.4. XML serialization
9.4.1. External references
9.4.2. Entity expansion
9.4.3. XInclude processing
9.4.4. Algorithmic complexity of XML validation
9.4.5. Using Expat for XML parsing
9.4.6. Using OpenJDK for XML parsing and validation
9.5. Protocol Encoders
- Protocol decoders and file format parsers are often the most-exposed part of an application because they are exposed with little or no user interaction and before any authentication and security checks are made. They are also difficult to write robustly in languages which are not memory-safe. -

9.1. Recommendations for manually written decoders

- For C and C++, the advice in Section 1.1.2, “Recommendations for pointers and array handling” applies. In addition, avoid non-character pointers directly into input buffers. Pointer misalignment causes crashes on some architectures. -
- When reading variable-sized objects, do not allocate large amounts of data solely based on the value of a size field. If possible, grow the data structure as more data is read from the source, and stop when no data is available. This helps to avoid denial-of-service attacks where little amounts of input data results in enormous memory allocations during decoding. Alternatively, you can impose reasonable bounds on memory allocations, but some protocols do not permit this. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Temporary_Directory.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Temporary_Directory.html deleted file mode 100644 index c5f6cbf..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Temporary_Directory.html +++ /dev/null @@ -1,8 +0,0 @@ - -7.4. Temporary directories

Product SiteDocumentation Site

7.4. Temporary directories

- The mkdtemp function can be used to create a temporary directory. (For determining the directory part of the file name pattern, see Section 7.1, “Obtaining the location of temporary directory”.) The directory is not automatically removed. In Python, this function is available as tempfile.mkdtemp. In Java 7, temporary directories can be created using the java.nio.file.Files.createTempDirectory(Path, String, FileAttribute...) function. -
- When creating files in the temporary directory, use automatically generated names, e.g., derived from a sequential counter. Files with externally provided names could be picked up in unexpected contexts, and crafted names could actually point outside of the tempoary directory (due to directory traversal). -
- Removing a directory tree in a completely safe manner is complicated. Unless there are overriding performance concerns, the rm program should be used, with the -rf and -- options. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Temporary_Files.html b/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Temporary_Files.html deleted file mode 100644 index cdd7de6..0000000 --- a/defensive-coding/tmp/en-US/html/chap-Defensive_Coding-Tasks-Temporary_Files.html +++ /dev/null @@ -1,28 +0,0 @@ - -Chapter 7. Temporary files

Product SiteDocumentation Site

Chapter 7. Temporary files

7.1. Obtaining the location of temporary directory
7.2. Named temporary files
7.3. Temporary files without names
7.4. Temporary directories
7.5. Compensating for unsafe file creation
- In this chapter, we describe how to create temporary files and directories, how to remove them, and how to work with programs which do not create files in ways that a safe with a shared directory for temporary files. General file system manipulation is treated in a separate chapter, Chapter 6, File system manipulation. -
- Secure creation of temporary files has four different aspects. -
  • - The location of the directory for temporary files must be obtained in a secure manner (that is, untrusted environment variables must be ignored, see Section 8.3.1, “Accessing environment variables”). -
  • - A new file must be created. Reusing an existing file must be avoided (the /tmp race condition). This is tricky because traditionally, system-wide temporary directories shared by all users are used. -
  • - The file must be created in a way that makes it impossible for other users to open it. -
  • - The descriptor for the temporary file should not leak to subprocesses. -
- All functions mentioned below will take care of these aspects. -
- Traditionally, temporary files are often used to reduce memory usage of programs. More and more systems use RAM-based file systems such as tmpfs for storing temporary files, to increase performance and decrease wear on Flash storage. As a result, spooling data to temporary files does not result in any memory savings, and the related complexity can be avoided if the data is kept in process memory. -

7.1. Obtaining the location of temporary directory

- Some functions below need the location of a directory which stores temporary files. For C/C++ programs, use the following steps to obtain that directory: -
  • - Use secure_getenv to obtain the value of the TMPDIR environment variable. If it is set, convert the path to a fully-resolved absolute path, using realpath(path, NULL). Check if the new path refers to a directory and is writeable. In this case, use it as the temporary directory. -
  • - Fall back to /tmp. -
- In Python, you can use the tempfile.tempdir variable. -
- Java does not support SUID/SGID programs, so you can use the java.lang.System.getenv(String) method to obtain the value of the TMPDIR environment variable, and follow the two steps described above. (Java's default directory selection does not honor TMPDIR.) -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/index.html b/defensive-coding/tmp/en-US/html/index.html deleted file mode 100644 index cf88211..0000000 --- a/defensive-coding/tmp/en-US/html/index.html +++ /dev/null @@ -1,34 +0,0 @@ - -Defensive Coding

Product SiteDocumentation Site

Internal 6.4

Defensive Coding

A Guide to Improving Software Security

Edition 1.0

- - -

Legal Notice

- Copyright © 2012 Red Hat, Inc. -
- The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. -
- Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. -
- Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. -
- Linux® is the registered trademark of Linus Torvalds in the United States and other countries. -
- Java® is a registered trademark of Oracle and/or its affiliates. -
- XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. -
- MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. -
- All other trademarks are the property of their respective owners. -
- -


- 1801 Varsity Drive
- Raleigh, NC 27606-2072 USA
- Phone: +1 919 754 3700
- Phone: 888 733 4281
- Fax: +1 919 754 3701

- -
Abstract
- This document provides guidelines for improving software security through secure coding. It covers common programming languages and libraries, and focuses on concrete recommendations. -
I. Programming Languages
1. The C Programming Language
1.1. The core language
1.1.1. Undefined behavior
1.1.2. Recommendations for pointers and array handling
1.1.3. Recommendations for integer arithmetic
1.2. The C standard library
1.2.1. Absolutely banned interfaces
1.2.2. Functions to avoid
1.2.3. String Functions With Explicit Length Arguments
1.3. Memory allocators
1.3.1. malloc and related functions
1.3.2. alloca and other forms of stack-based allocation
1.3.3. Array allocation
1.3.4. Custom memory allocators
1.3.5. Conservative garbage collection
2. The C++ Programming Language
2.1. The core language
2.1.1. Array allocation with operator new[]
2.1.2. Overloading
2.1.3. ABI compatibility and preparing for security updates
2.1.4. C++0X and C++11 support
2.2. The C++ standard library
2.2.1. Containers and operator[]
3. The Python Programming Language
3.1. Dangerous standard library features
3.2. Run-time compilation and code generation
3.3. Sandboxing
II. Specific Programming Tasks
4. Library Design
4.1. State management
4.1.1. Global state
4.1.2. Handles
4.2. Object orientation
4.3. Callbacks
4.4. Process attributes
5. File Descriptor Management
5.1. Closing descriptors
5.1.1. Error handling during descriptor close
5.1.2. Closing descriptors and race conditions
5.1.3. Lingering state after close
5.2. Preventing file descriptor leaks to child processes
5.3. Dealing with the select limit
6. File system manipulation
6.1. Working with files and directories owned by other users
6.2. Accessing the file system as a different user
6.3. File system limits
6.4. File system features
6.5. Checking free space
7. Temporary files
7.1. Obtaining the location of temporary directory
7.2. Named temporary files
7.3. Temporary files without names
7.4. Temporary directories
7.5. Compensating for unsafe file creation
8. Processes
8.1. Safe process creation
8.1.1. Obtaining the program path and the command line template
8.1.2. Bypassing the shell
8.1.3. Specifying the process environment
8.1.4. Robust argument list processing
8.1.5. Passing secrets to subprocesses
8.2. Handling child process termination
8.3. SUID/SGID processes
8.3.1. Accessing environment variables
8.4. Daemons
8.5. Semantics of command line arguments
8.6. fork as a primitive for parallelism
9. Serialization and Deserialization
9.1. Recommendations for manually written decoders
9.2. Protocol design
9.3. Library support for deserialization
9.4. XML serialization
9.4.1. External references
9.4.2. Entity expansion
9.4.3. XInclude processing
9.4.4. Algorithmic complexity of XML validation
9.4.5. Using Expat for XML parsing
9.4.6. Using OpenJDK for XML parsing and validation
9.5. Protocol Encoders
10. Cryptography
10.1. Primitives
10.2. Randomness
III. Implementing Security Features
11. Authentication and Authorization
11.1. Authenticating servers
11.2. Host-based authentication
11.3. UNIX domain socket authentication
11.4. AF_NETLINK authentication of origin
12. Transport Layer Security
12.1. Common Pitfalls
12.1.1. OpenSSL Pitfalls
12.1.2. GNUTLS Pitfalls
12.1.3. OpenJDK Pitfalls
12.1.4. NSS Pitfalls
12.2. TLS Clients
12.2.1. Implementation TLS Clients With OpenSSL
12.2.2. Implementation TLS Clients With GNUTLS
12.2.3. Implementing TLS Clients With OpenJDK
12.2.4. Implementing TLS Clients With NSS
12.2.5. Implementing TLS Clients With Python
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/pt01.html b/defensive-coding/tmp/en-US/html/pt01.html deleted file mode 100644 index 2956dc9..0000000 --- a/defensive-coding/tmp/en-US/html/pt01.html +++ /dev/null @@ -1,2 +0,0 @@ - -Part I. Programming Languages

Product SiteDocumentation Site

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/pt02.html b/defensive-coding/tmp/en-US/html/pt02.html deleted file mode 100644 index 06a5b00..0000000 --- a/defensive-coding/tmp/en-US/html/pt02.html +++ /dev/null @@ -1,2 +0,0 @@ - -Part II. Specific Programming Tasks

Product SiteDocumentation Site

Part II. Specific Programming Tasks

Table of Contents

4. Library Design
4.1. State management
4.1.1. Global state
4.1.2. Handles
4.2. Object orientation
4.3. Callbacks
4.4. Process attributes
5. File Descriptor Management
5.1. Closing descriptors
5.1.1. Error handling during descriptor close
5.1.2. Closing descriptors and race conditions
5.1.3. Lingering state after close
5.2. Preventing file descriptor leaks to child processes
5.3. Dealing with the select limit
6. File system manipulation
6.1. Working with files and directories owned by other users
6.2. Accessing the file system as a different user
6.3. File system limits
6.4. File system features
6.5. Checking free space
7. Temporary files
7.1. Obtaining the location of temporary directory
7.2. Named temporary files
7.3. Temporary files without names
7.4. Temporary directories
7.5. Compensating for unsafe file creation
8. Processes
8.1. Safe process creation
8.1.1. Obtaining the program path and the command line template
8.1.2. Bypassing the shell
8.1.3. Specifying the process environment
8.1.4. Robust argument list processing
8.1.5. Passing secrets to subprocesses
8.2. Handling child process termination
8.3. SUID/SGID processes
8.3.1. Accessing environment variables
8.4. Daemons
8.5. Semantics of command line arguments
8.6. fork as a primitive for parallelism
9. Serialization and Deserialization
9.1. Recommendations for manually written decoders
9.2. Protocol design
9.3. Library support for deserialization
9.4. XML serialization
9.4.1. External references
9.4.2. Entity expansion
9.4.3. XInclude processing
9.4.4. Algorithmic complexity of XML validation
9.4.5. Using Expat for XML parsing
9.4.6. Using OpenJDK for XML parsing and validation
9.5. Protocol Encoders
10. Cryptography
10.1. Primitives
10.2. Randomness
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/pt03.html b/defensive-coding/tmp/en-US/html/pt03.html deleted file mode 100644 index df42c39..0000000 --- a/defensive-coding/tmp/en-US/html/pt03.html +++ /dev/null @@ -1,2 +0,0 @@ - -Part III. Implementing Security Features

Product SiteDocumentation Site

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-Host_based.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-Host_based.html deleted file mode 100644 index 60dbe7d..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-Host_based.html +++ /dev/null @@ -1,14 +0,0 @@ - -11.2. Host-based authentication

Product SiteDocumentation Site

11.2. Host-based authentication

- Host-based authentication uses access control lists (ACLs) to accept or deny requests from clients. Thsis authentication method comes in two flavors: IP-based (or, more generally, address-based) and name-based (with the name coming from DNS or /etc/hosts). IP-based ACLs often use prefix notation to extend access to entire subnets. Name-based ACLs sometimes use wildcards for adding groups of hosts (from entire DNS subtrees). (In the SSH context, host-based authentication means something completely different and is not covered in this section.) -
- Host-based authentication trust the network and may not offer sufficient granularity, so it has to be considered a weak form of authentication. On the other hand, IP-based authentication can be made extremely robust and can be applied very early in input processing, so it offers an opportunity for significantly reducing the number of potential attackers for many services. -
- The names returned by gethostbyaddr and getnameinfo functions cannot be trusted. (DNS PTR records can be set to arbitrary values, not just names belong to the address owner.) If these names are used for ACL matching, a forward lookup using gethostbyaddr or getaddrinfo has to be performed. The name is only valid if the original address is found among the results of the forward lookup (double-reverse lookup). -
- An empty ACL should deny all access (deny-by-default). If empty ACLs permits all access, configuring any access list must switch to deny-by-default for all unconfigured protocols, in both name-based and address-based variants. -
- Similarly, if an address or name is not matched by the list, it should be denied. However, many implementations behave differently, so the actual behavior must be documented properly. -
- IPv6 addresses can embed IPv4 addresses. There is no universally correct way to deal with this ambiguity. The behavior of the ACL implementation should be documented. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-Netlink.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-Netlink.html deleted file mode 100644 index d3536c8..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-Netlink.html +++ /dev/null @@ -1,8 +0,0 @@ - -11.4. AF_NETLINK authentication of origin

Product SiteDocumentation Site

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-UNIX_Domain.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-UNIX_Domain.html deleted file mode 100644 index 9e30ada..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Authentication-UNIX_Domain.html +++ /dev/null @@ -1,10 +0,0 @@ - -11.3. UNIX domain socket authentication

Product SiteDocumentation Site

11.3. UNIX domain socket authentication

- UNIX domain sockets (with address family AF_UNIX or AF_LOCAL) are restricted to the local host and offer a special authentication mechanism: credentials passing. -
- Nowadays, most systems support the SO_PEERCRED (Linux) or LOCAL_PEERCRED (FreeBSD) socket options, or the getpeereid (other BSDs, MacOS X). These interfaces provide direct access to the (effective) user ID on the other end of a domain socket connect, without cooperation from the other end. -
- Historically, credentials passing was implemented using ancillary data in the sendmsg and recvmsg functions. On some systems, only credentials data that the peer has explicitly sent can be received, and the kernel checks the data for correctness on the sending side. This means that both peers need to deal with ancillary data. Compared to that, the modern interfaces are easier to use. Both sets of interfaces vary considerably among UNIX-like systems, unfortunately. -
- If you want to authenticate based on supplementary groups, you should obtain the user ID using one of these methods, and look up the list of supplementary groups using getpwuid (or getpwuid_r) and getgrouplist. Using the PID and information from /proc/PID/status is prone to race conditions and insecure. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators-Arrays.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators-Arrays.html deleted file mode 100644 index cb1fa45..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators-Arrays.html +++ /dev/null @@ -1,6 +0,0 @@ - -1.3.3. Array allocation

Product SiteDocumentation Site

1.3.3. Array allocation

- When allocating arrays, it is important to check for overflows. The calloc function performs such checks. -
- If malloc or realloc is used, the size check must be written manually. For instance, to allocate an array of n elements of type T, check that the requested size is not greater than n / sizeof(T). -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators-alloca.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators-alloca.html deleted file mode 100644 index 471595d..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators-alloca.html +++ /dev/null @@ -1,14 +0,0 @@ - -1.3.2. alloca and other forms of stack-based allocation

Product SiteDocumentation Site

1.3.2. alloca and other forms of stack-based allocation

- Allocation on the stack is risky because stack overflow checking is implicit. There is a guard page at the end of the memory area reserved for the stack. If the program attempts to read from or write to this guard page, a SIGSEGV signal is generated and the program typically terminates. -
- This is sufficient for detecting typical stack overflow situations such as unbounded recursion, but it fails when the stack grows in increments larger than the size of the guard page. In this case, it is possible that the stack pointer ends up pointing into a memory area which has been allocated for a different purposes. Such misbehavior can be exploitable. -
- A common source for large stack growth are calls to alloca and related functions such as strdupa. These functions should be avoided because of the lack of error checking. (They can be used safely if the allocated size is less than the page size (typically, 4096 bytes), but this case is relatively rare.) Additionally, relying on alloca makes it more difficult to reorgnize the code because it is not allowed to use the pointer after the function calling alloca has returned, even if this function has been inlined into its caller. -
- Similar concerns apply to variable-length arrays (VLAs), a feature of the C99 standard which started as a GNU extension. For large objects exceeding the page size, there is no error checking, either. -
- In both cases, negative or very large sizes can trigger a stack-pointer wraparound, and the stack pointer and end up pointing into caller stack frames, which is fatal and can be exploitable. -
- If you want to use alloca or VLAs for performance reasons, consider using a small on-stack array (less than the page size, large enough to fulfill most requests). If the requested size is small enough, use the on-stack array. Otherwise, call malloc. When exiting the function, check if malloc had been called, and free the buffer as needed. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators.html deleted file mode 100644 index b378289..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Allocators.html +++ /dev/null @@ -1,16 +0,0 @@ - -1.3. Memory allocators

Product SiteDocumentation Site

1.3. Memory allocators

1.3.1. malloc and related functions

- The C library interfaces for memory allocation are provided by malloc, free and realloc, and the calloc function. In addition to these generic functions, there are derived functions such as strdup which perform allocation using malloc internally, but do not return untyped heap memory (which could be used for any object). -
- The C compiler knows about these functions and can use their expected behavior for optimizations. For instance, the compiler assumes that an existing pointer (or a pointer derived from an existing pointer by arithmetic) will not point into the memory area returned by malloc. -
- If the allocation fails, realloc does not free the old pointer. Therefore, the idiom ptr = realloc(ptr, size); is wrong because the memory pointed to by ptr leaks in case of an error. -

1.3.1.1. Use-after-free errors

- After free, the pointer is invalid. Further pointer dereferences are not allowed (and are usually detected by valgrind). Less obvious is that any use of the old pointer value is not allowed, either. In particular, comparisons with any other pointer (or the null pointer) are undefined according to the C standard. -
- The same rules apply to realloc if the memory area cannot be enlarged in-place. For instance, the compiler may assume that a comparison between the old and new pointer will always return false, so it is impossible to detect movement this way. -

1.3.1.2. Handling memory allocation errors

- Recovering from out-of-memory errors is often difficult or even impossible. In these cases, malloc and other allocation functions return a null pointer. Dereferencing this pointer lead to a crash. Such dereferences can even be exploitable for code execution if the dereference is combined with an array subscript. -
- In general, if you cannot check all allocation calls and handle failure, you should abort the program on allocation failure, and not rely on the null pointer dereference to terminate the process. See Section 9.1, “Recommendations for manually written decoders” for related memory allocation concerns. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Avoid.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Avoid.html deleted file mode 100644 index 0c44c7a..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Avoid.html +++ /dev/null @@ -1,28 +0,0 @@ - -1.2.2. Functions to avoid

Product SiteDocumentation Site

1.2.2. Functions to avoid

- The following string manipulation functions can be used securely in principle, but their use should be avoided because they are difficult to use correctly. Calls to these functions can be replaced with asprintf or vasprintf. (For non-GNU targets, these functions are available from Gnulib.) In some cases, the snprintf function might be a suitable replacement, see Section 1.2.3, “String Functions With Explicit Length Arguments”. -
  • - sprintf -
  • - strcat -
  • - strcpy -
  • - vsprintf -
- Use the indicated replacements for the functions below. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Libc.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Libc.html deleted file mode 100644 index fe94d1b..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-Libc.html +++ /dev/null @@ -1,30 +0,0 @@ - -1.2. The C standard library

Product SiteDocumentation Site

1.2. The C standard library

- Parts of the C standard library (and the UNIX and GNU extensions) are difficult to use, so you shoud avoid them. -
- Please check the applicable documentation before using the recommended replacements. Many of these functions allocate buffers using malloc which your code must deallocate explicitly using free. -

1.2.1. Absolutely banned interfaces

- The functions listed below must not be used because they are almost always unsafe. Use the indicated replacements instead. -
  • - gets ⟶ fgets -
  • - getwd ⟶ getcwd or get_current_dir_name -
  • - readdir_r ⟶ readdir -
  • - realpath (with a non-NULL second parameter) ⟶ realpath with NULL as the second parameter, or canonicalize_file_name -
- The constants listed below must not be used, either. Instead, code must allocate memory dynamically and use interfaces with length checking. -
  • - NAME_MAX (limit not actually enforced by the kernel) -
  • - PATH_MAX (limit not actually enforced by the kernel) -
  • - _PC_NAME_MAX (This limit, returned by the pathconf function, is not enforced by the kernel.) -
  • - _PC_PATH_MAX (This limit, returned by the pathconf function, is not enforced by the kernel.) -
- The following structure members must not be used. -
  • - f_namemax in struct statvfs (limit not actually enforced by the kernel, see _PC_NAME_MAX above) -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-String-Functions-Length.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-String-Functions-Length.html deleted file mode 100644 index aee5e94..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-C-String-Functions-Length.html +++ /dev/null @@ -1,32 +0,0 @@ - -1.2.3. String Functions With Explicit Length Arguments

Product SiteDocumentation Site

1.2.3. String Functions With Explicit Length Arguments

- The snprintf function provides a way to construct a string in a statically-sized buffer. (If the buffer size is dynamic, use asprintf instead.) - 
-char fraction[30];
-snprintf(fraction, sizeof(fraction), "%d/%d", numerator, denominator);
-
- The second argument to the snprintf should always be the size of the buffer in the first argument (which should be a character array). Complex pointer and length arithmetic can introduce errors and nullify the security benefits of snprintf. If you need to construct a string iteratively, by repeatedly appending fragments, consider constructing the string on the heap, increasing the buffer with realloc as needed. (snprintf does not support overlapping the result buffer with argument strings.) -
- If you use vsnprintf (or snprintf) with a format string which is not a constant, but a function argument, it is important to annotate the function with a format function attribute, so that GCC can warn about misuse of your function (see Example 1.4, “The format function attribute”). -
Example 1.4. The format function attribute
-void log_format(const char *format, ...) __attribute__((format(printf, 1, 2)));
-
-void
-log_format(const char *format, ...)
-{
-  char buf[1000];
-  va_list ap;
-  va_start(ap, format);
-  vsnprintf(buf, sizeof(buf), format, ap);
-  va_end(ap);
-  log_string(buf);
-}
-

- There are other functions which operator on NUL-terminated strings and take a length argument which affects the number of bytes written to the destination: strncpy, strncat, and stpncpy. These functions do not ensure that the result string is NUL-terminated. For strncpy, NUL termination can be added this way: - 
-char buf[10];
-strncpy(buf, data, sizeof(buf));
-buf[sizeof(buf) - 1] = '\0';
-
- Some systems support strlcpy and strlcat functions which behave this way, but these functions are not part of GNU libc. Using snprintf with a suitable format string is a simple (albeit slightly slower) replacement. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-CXX-Std.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-CXX-Std.html deleted file mode 100644 index 61d73c9..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-CXX-Std.html +++ /dev/null @@ -1,8 +0,0 @@ - -2.2. The C++ standard library

Product SiteDocumentation Site

2.2. The C++ standard library

- The C++ standard library includes most of its C counterpart by reference, see Section 1.2, “The C standard library”. -

2.2.1. Containers and operator[]

- Many containers similar to std::vector provide both operator[](size_type) and a member function at(size_type). This applies to std::vector itself, std::array, std::string and other instances of std::basic_string. -
- operator[](size_type) is not required by the standard to perform bounds checking (and the implementation in GCC does not). In contrast, at(size_type) must perform such a check. Therefore, in code which is not performance-critical, you should prefer at(size_type) over operator[](size_type), even though it is slightly more verbose. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-GNUTLS.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-GNUTLS.html deleted file mode 100644 index df506ec..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-GNUTLS.html +++ /dev/null @@ -1,183 +0,0 @@ - -12.2.2. Implementation TLS Clients With GNUTLS

Product SiteDocumentation Site

12.2.2. Implementation TLS Clients With GNUTLS

- This section describes how to implement a TLS client with full certificate validation (but without certificate revocation checking). Note that the error handling in is only exploratory and needs to be replaced before production use. -
- The GNUTLS library needs explicit initialization: - 
-gnutls_global_init();
-
- Failing to do so can result in obscure failures in Base64 decoding. See Section 12.1.2, “GNUTLS Pitfalls” for additional aspects of initialization. -
- Before setting up TLS connections, a credentials objects has to be allocated and initialized with the set of trusted root CAs (Example 12.9, “Initializing a GNUTLS credentials structure”). -
Example 12.9. Initializing a GNUTLS credentials structure
-// Load the trusted CA certificates.
-gnutls_certificate_credentials_t cred = NULL;
-int ret = gnutls_certificate_allocate_credentials (&cred);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_certificate_allocate_credentials: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-// gnutls_certificate_set_x509_system_trust needs GNUTLS version 3.0
-// or newer, so we hard-code the path to the certificate store
-// instead.
-static const char ca_bundle[] = "/etc/ssl/certs/ca-bundle.crt";
-ret = gnutls_certificate_set_x509_trust_file
-  (cred, ca_bundle, GNUTLS_X509_FMT_PEM);
-if (ret == 0) {
-  fprintf(stderr, "error: no certificates found in: %s\n", ca_bundle);
-  exit(1);
-}
-if (ret < 0) {
-  fprintf(stderr, "error: gnutls_certificate_set_x509_trust_files(%s): %s\n",
-	    ca_bundle, gnutls_strerror(ret));
-  exit(1);
-}
-

- After the last TLS connection has been closed, this credentials object should be freed: - 
-gnutls_certificate_free_credentials(cred);
-
- During its lifetime, the credentials object can be used to initialize TLS session objects from multiple threads, provided that it is not changed. -
- Once the TCP connection has been established, the Nagle algorithm should be disabled (see Example 12.1, “Deactivating the TCP Nagle algorithm”). After that, the socket can be associated with a new GNUTLS session object. The previously allocated credentials object provides the set of root CAs. The NORMAL set of cipher suites and protocols provides a reasonable default. Then the TLS handshake must be initiated. This is shown in Example 12.10, “Establishing a TLS client connection using GNUTLS”. -
Example 12.10. Establishing a TLS client connection using GNUTLS
-// Create the session object.
-gnutls_session_t session;
-ret = gnutls_init(&session, GNUTLS_CLIENT);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_init: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-
-// Configure the cipher preferences.
-const char *errptr = NULL;
-ret = gnutls_priority_set_direct(session, "NORMAL", &errptr);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_priority_set_direct: %s\n"
-	    "error: at: \"%s\"\n", gnutls_strerror(ret), errptr);
-  exit(1);
-}
-
-// Install the trusted certificates.
-ret = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, cred);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_credentials_set: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-
-// Associate the socket with the session object and set the server
-// name.
-gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t)(uintptr_t)sockfd);
-ret = gnutls_server_name_set(session, GNUTLS_NAME_DNS,
-			       host, strlen(host));
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_server_name_set: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-
-// Establish the session.
-ret = gnutls_handshake(session);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_handshake: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-

- After the handshake has been completed, the server certificate needs to be verified (Example 12.11, “Verifying a server certificate using GNUTLS”). In the example, the user-defined certificate_validity_override function is called if the verification fails, so that a separate, user-specific trust store can be checked. This function call can be omitted if the functionality is not needed. -
Example 12.11. Verifying a server certificate using GNUTLS
-// Obtain the server certificate chain.  The server certificate
-// itself is stored in the first element of the array.
-unsigned certslen = 0;
-const gnutls_datum_t *const certs =
-  gnutls_certificate_get_peers(session, &certslen);
-if (certs == NULL || certslen == 0) {
-  fprintf(stderr, "error: could not obtain peer certificate\n");
-  exit(1);
-}
-
-// Validate the certificate chain.
-unsigned status = (unsigned)-1;
-ret = gnutls_certificate_verify_peers2(session, &status);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_certificate_verify_peers2: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-if (status != 0 && !certificate_validity_override(certs[0])) {
-  gnutls_datum_t msg;
-#if GNUTLS_VERSION_AT_LEAST_3_1_4
-  int type = gnutls_certificate_type_get (session);
-  ret = gnutls_certificate_verification_status_print(status, type, &out, 0);
-#else
-  ret = -1;
-#endif
-  if (ret == 0) {
-    fprintf(stderr, "error: %s\n", msg.data);
-    gnutls_free(msg.data);
-    exit(1);
-  } else {
-    fprintf(stderr, "error: certificate validation failed with code 0x%x\n",
-	      status);
-    exit(1);
-  }
-}
-

- In the next step (Example 12.12, “Matching the server host name and certificate in a GNUTLS client”, the certificate must be matched against the host name (note the unusual return value from gnutls_x509_crt_check_hostname). Again, an override function certificate_host_name_override is called. Note that the override must be keyed to the certificate and the host name. The function call can be omitted if the override is not needed. -
Example 12.12. Matching the server host name and certificate in a GNUTLS client
-// Match the peer certificate against the host name.
-// We can only obtain a set of DER-encoded certificates from the
-// session object, so we have to re-parse the peer certificate into
-// a certificate object.
-gnutls_x509_crt_t cert;
-ret = gnutls_x509_crt_init(&cert);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_x509_crt_init: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-// The peer certificate is the first certificate in the list.
-ret = gnutls_x509_crt_import(cert, certs, GNUTLS_X509_FMT_DER);
-if (ret != GNUTLS_E_SUCCESS) {
-  fprintf(stderr, "error: gnutls_x509_crt_import: %s\n",
-	    gnutls_strerror(ret));
-  exit(1);
-}
-ret = gnutls_x509_crt_check_hostname(cert, host);
-if (ret == 0 && !certificate_host_name_override(certs[0], host)) {
-  fprintf(stderr, "error: host name does not match certificate\n");
-  exit(1);
-}
-gnutls_x509_crt_deinit(cert);
-

- In newer GNUTLS versions, certificate checking and host name validation can be combined using the gnutls_certificate_verify_peers3 function. -
- An established TLS session can be used for sending and receiving data, as in Example 12.13, “Using a GNUTLS session”. -
Example 12.13. Using a GNUTLS session
-char buf[4096];
-snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host);
-ret = gnutls_record_send(session, buf, strlen(buf));
-if (ret < 0) {
-  fprintf(stderr, "error: gnutls_record_send: %s\n", gnutls_strerror(ret));
-  exit(1);
-}
-ret = gnutls_record_recv(session, buf, sizeof(buf));
-if (ret < 0) {
-  fprintf(stderr, "error: gnutls_record_recv: %s\n", gnutls_strerror(ret));
-  exit(1);
-}
-

- In order to shut down a connection in an orderly manner, you should call the gnutls_bye function. Finally, the session object can be deallocated using gnutls_deinit (see Example 12.14, “Using a GNUTLS session”). -
Example 12.14. Using a GNUTLS session
-// Initiate an orderly connection shutdown.
-ret = gnutls_bye(session, GNUTLS_SHUT_RDWR);
-if (ret < 0) {
-  fprintf(stderr, "error: gnutls_bye: %s\n", gnutls_strerror(ret));
-  exit(1);
-}
-// Free the session object.
-gnutls_deinit(session);
-

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-NSS.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-NSS.html deleted file mode 100644 index 36f588b..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-NSS.html +++ /dev/null @@ -1,226 +0,0 @@ - -12.2.4. Implementing TLS Clients With NSS

Product SiteDocumentation Site

12.2.4. Implementing TLS Clients With NSS

- The following code shows how to implement a simple TLS client using NSS. Note that the error handling needs replacing before production use. -
- Using NSS needs several header files, as shown in Example 12.21, “Include files for NSS”. -
Example 12.21. Include files for NSS
-// NSPR include files
-#include <prerror.h>
-#include <prinit.h>
-
-// NSS include files
-#include <nss.h>
-#include <pk11pub.h>
-#include <secmod.h>
-#include <ssl.h>
-#include <sslproto.h>
-
-// Private API, no other way to turn a POSIX file descriptor into an
-// NSPR handle.
-NSPR_API(PRFileDesc*) PR_ImportTCPSocket(int);
-

- Initializing the NSS library is a complex task (Example 12.22, “Initializing the NSS library”). It is not thread-safe. By default, the library is in export mode, and all strong ciphers are disabled. Therefore, after creating the NSSInitCContext object, we probe all the strong ciphers we want to use, and check if at least one of them is available. If not, we call NSS_SetDomesticPolicy to switch to unrestricted policy mode. This function replaces the existing global cipher suite policy, that is why we avoid calling it unless absolutely necessary. -
- The simplest way to configured the trusted root certificates involves loading the libnssckbi.so NSS module with a call to the SECMOD_LoadUserModule function. The root certificates are compiled into this module. (The PEM module for NSS, libnsspem.so, offers a way to load trusted CA certificates from a file.) -
Example 12.22. Initializing the NSS library
-PR_Init(PR_USER_THREAD, PR_PRIORITY_NORMAL, 0);
-NSSInitContext *const ctx =
-  NSS_InitContext("sql:/etc/pki/nssdb", "", "", "", NULL,
-		    NSS_INIT_READONLY | NSS_INIT_PK11RELOAD);
-if (ctx == NULL) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: NSPR error code %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-
-// Ciphers to enable.
-static const PRUint16 good_ciphers[] = {
-  TLS_RSA_WITH_AES_128_CBC_SHA,
-  TLS_RSA_WITH_AES_256_CBC_SHA,
-  SSL_RSA_WITH_3DES_EDE_CBC_SHA,
-  SSL_NULL_WITH_NULL_NULL // sentinel
-};
-
-// Check if the current policy allows any strong ciphers.  If it
-// doesn't, switch to the "domestic" (unrestricted) policy.  This is
-// not thread-safe and has global impact.  Consequently, we only do
-// it if absolutely necessary.
-int found_good_cipher = 0;
-for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL;
-     ++p) {
-  PRInt32 policy;
-  if (SSL_CipherPolicyGet(*p, &policy) != SECSuccess) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: policy for cipher %u: error %d: %s\n",
-	      (unsigned)*p, err, PR_ErrorToName(err));
-    exit(1);
-  }
-  if (policy == SSL_ALLOWED) {
-    fprintf(stderr, "info: found cipher %x\n", (unsigned)*p);
-    found_good_cipher = 1;
-    break;
-  }
-}
-if (!found_good_cipher) {
-  if (NSS_SetDomesticPolicy() != SECSuccess) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: NSS_SetDomesticPolicy: error %d: %s\n",
-	      err, PR_ErrorToName(err));
-    exit(1);
-  }
-}
-
-// Initialize the trusted certificate store.
-char module_name[] = "library=libnssckbi.so name=\"Root Certs\"";
-SECMODModule *module = SECMOD_LoadUserModule(module_name, NULL, PR_FALSE);
-if (module == NULL || !module->loaded) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: NSPR error code %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-

- Some of the effects of the initialization can be reverted with the following function calls: - 
-SECMOD_DestroyModule(module);
-NSS_ShutdownContext(ctx);
-
- After NSS has been initialized, the TLS connection can be created (Example 12.23, “Creating a TLS connection with NSS”). The internal PR_ImportTCPSocket function is used to turn the POSIX file descriptor sockfd into an NSPR file descriptor. (This function is de-facto part of the NSS public ABI, so it will not go away.) Creating the TLS-capable file descriptor requires a model descriptor, which is configured with the desired set of protocols and ciphers. (The good_ciphers variable is part of Example 12.22, “Initializing the NSS library”.) We cannot resort to disabling ciphers not on a whitelist because by default, the AES cipher suites are disabled. The model descriptor is not needed anymore after TLS support has been activated for the existing connection descriptor. -
- The call to SSL_BadCertHook can be omitted if no mechanism to override certificate verification is needed. The bad_certificate function must check both the host name specified for the connection and the certificate before granting the override. -
- Triggering the actual handshake requires three function calls, SSL_ResetHandshake, SSL_SetURL, and SSL_ForceHandshake. (If SSL_ResetHandshake is omitted, SSL_ForceHandshake will succeed, but the data will not be encrypted.) During the handshake, the certificate is verified and matched against the host name. -
Example 12.23. Creating a TLS connection with NSS
-// Wrap the POSIX file descriptor.  This is an internal NSPR
-// function, but it is very unlikely to change.
-PRFileDesc* nspr = PR_ImportTCPSocket(sockfd);
-sockfd = -1; // Has been taken over by NSPR.
-
-// Add the SSL layer.
-{
-  PRFileDesc *model = PR_NewTCPSocket();
-  PRFileDesc *newfd = SSL_ImportFD(NULL, model);
-  if (newfd == NULL) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: NSPR error code %d: %s\n",
-	      err, PR_ErrorToName(err));
-    exit(1);
-  }
-  model = newfd;
-  newfd = NULL;
-  if (SSL_OptionSet(model, SSL_ENABLE_SSL2, PR_FALSE) != SECSuccess) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: set SSL_ENABLE_SSL2 error %d: %s\n",
-	      err, PR_ErrorToName(err));
-    exit(1);
-  }
-  if (SSL_OptionSet(model, SSL_V2_COMPATIBLE_HELLO, PR_FALSE) != SECSuccess) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: set SSL_V2_COMPATIBLE_HELLO error %d: %s\n",
-	      err, PR_ErrorToName(err));
-    exit(1);
-  }
-  if (SSL_OptionSet(model, SSL_ENABLE_DEFLATE, PR_FALSE) != SECSuccess) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: set SSL_ENABLE_DEFLATE error %d: %s\n",
-	      err, PR_ErrorToName(err));
-    exit(1);
-  }
-
-  // Disable all ciphers (except RC4-based ciphers, for backwards
-  // compatibility).
-  const PRUint16 *const ciphers = SSL_GetImplementedCiphers();
-  for (unsigned i = 0; i < SSL_GetNumImplementedCiphers(); i++) {
-    if (ciphers[i] != SSL_RSA_WITH_RC4_128_SHA
-	  && ciphers[i] != SSL_RSA_WITH_RC4_128_MD5) {
-	if (SSL_CipherPrefSet(model, ciphers[i], PR_FALSE) != SECSuccess) {
-	  const PRErrorCode err = PR_GetError();
-	  fprintf(stderr, "error: disable cipher %u: error %d: %s\n",
-		  (unsigned)ciphers[i], err, PR_ErrorToName(err));
-	  exit(1);
-	}
-    }
-  }
-
-  // Enable the strong ciphers.
-  for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL;
-	 ++p) {
-    if (SSL_CipherPrefSet(model, *p, PR_TRUE) != SECSuccess) {
-	const PRErrorCode err = PR_GetError();
-	fprintf(stderr, "error: enable cipher %u: error %d: %s\n",
-		(unsigned)*p, err, PR_ErrorToName(err));
-	exit(1);
-    }
-  }
-
-  // Allow overriding invalid certificate.
-  if (SSL_BadCertHook(model, bad_certificate, (char *)host) != SECSuccess) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: SSL_BadCertHook error %d: %s\n",
-	      err, PR_ErrorToName(err));
-    exit(1);
-  }
-
-  newfd = SSL_ImportFD(model, nspr);
-  if (newfd == NULL) {
-    const PRErrorCode err = PR_GetError();
-    fprintf(stderr, "error: SSL_ImportFD error %d: %s\n",
-	      err, PR_ErrorToName(err));
-    exit(1);
-  }
-  nspr = newfd;
-  PR_Close(model);
-}
-
-// Perform the handshake.
-if (SSL_ResetHandshake(nspr, PR_FALSE) != SECSuccess) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: SSL_ResetHandshake error %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-if (SSL_SetURL(nspr, host) != SECSuccess) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: SSL_SetURL error %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-if (SSL_ForceHandshake(nspr) != SECSuccess) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: SSL_ForceHandshake error %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-

- After the connection has been established, Example 12.24, “Using NSS for sending and receiving data” shows how to use the NSPR descriptor to communicate with the server. -
Example 12.24. Using NSS for sending and receiving data
-char buf[4096];
-snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host);
-PRInt32 ret = PR_Write(nspr, buf, strlen(buf));
-if (ret < 0) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: PR_Write error %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-ret = PR_Read(nspr, buf, sizeof(buf));
-if (ret < 0) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: PR_Read error %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-

- Example 12.25, “Closing NSS client connections” shows how to close the connection. -
Example 12.25. Closing NSS client connections
-// Send close_notify alert.
-if (PR_Shutdown(nspr, PR_SHUTDOWN_BOTH) != PR_SUCCESS) {
-  const PRErrorCode err = PR_GetError();
-  fprintf(stderr, "error: PR_Read error %d: %s\n",
-	    err, PR_ErrorToName(err));
-  exit(1);
-}
-// Closes the underlying POSIX file descriptor, too.
-PR_Close(nspr);
-

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-OpenJDK.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-OpenJDK.html deleted file mode 100644 index e26973d..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-OpenJDK.html +++ /dev/null @@ -1,165 +0,0 @@ - -12.2.3. Implementing TLS Clients With OpenJDK

Product SiteDocumentation Site

12.2.3. Implementing TLS Clients With OpenJDK

- The examples below use the following cryptographic-related classes: - 
-import java.security.NoSuchAlgorithmException;
-import java.security.NoSuchProviderException;
-import java.security.cert.CertificateEncodingException;
-import java.security.cert.CertificateException;
-import java.security.cert.X509Certificate;
-import javax.net.ssl.SSLContext;
-import javax.net.ssl.SSLParameters;
-import javax.net.ssl.SSLSocket;
-import javax.net.ssl.TrustManager;
-import javax.net.ssl.X509TrustManager;
-
-import sun.security.util.HostnameChecker;
-
- If compatibility with OpenJDK 6 is required, it is necessary to use the internal class sun.security.util.HostnameChecker. (The public OpenJDK API does not provide any support for dissecting the subject distinguished name of an X.509 certificate, so a custom-written DER parser is needed—or we have to use an internal class, which we do below.) In OpenJDK 7, the setEndpointIdentificationAlgorithm method was added to the javax.net.ssl.SSLParameters class, providing an official way to implement host name checking. -
- TLS connections are established using an SSLContext instance. With a properly configured OpenJDK installation, the SunJSSE provider uses the system-wide set of trusted root certificate authorities, so no further configuration is necessary. For backwards compatibility with OpenJDK 6, the TLSv1 provider has to be supported as a fall-back option. This is shown in Example 12.15, “Setting up an SSLContext for OpenJDK TLS clients”. -
Example 12.15. Setting up an SSLContext for OpenJDK TLS clients
-// Create the context.  Specify the SunJSSE provider to avoid
-// picking up third-party providers.  Try the TLS 1.2 provider
-// first, then fall back to TLS 1.0.
-SSLContext ctx;
-try {
-    ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE");
-} catch (NoSuchAlgorithmException e) {
-    try {
-        ctx = SSLContext.getInstance("TLSv1", "SunJSSE");
-    } catch (NoSuchAlgorithmException e1) {
-        // The TLS 1.0 provider should always be available.
-        throw new AssertionError(e1);
-    } catch (NoSuchProviderException e1) {
-        throw new AssertionError(e1);
-    } 
-} catch (NoSuchProviderException e) {
-    // The SunJSSE provider should always be available.
-    throw new AssertionError(e);
-}
-ctx.init(null, null, null);
-

- In addition to the context, a TLS parameter object will be needed which adjusts the cipher suites and protocols (Example 12.16, “Setting up SSLParameters for TLS use with OpenJDK”). Like the context, these parameters can be reused for multiple TLS connections. -
Example 12.16. Setting up SSLParameters for TLS use with OpenJDK
-// Prepare TLS parameters.  These have to applied to every TLS
-// socket before the handshake is triggered.
-SSLParameters params = ctx.getDefaultSSLParameters();
-// Do not send an SSL-2.0-compatible Client Hello.
-ArrayList<String> protocols = new ArrayList<String>(
-    Arrays.asList(params.getProtocols()));
-protocols.remove("SSLv2Hello");
-params.setProtocols(protocols.toArray(new String[protocols.size()]));
-// Adjust the supported ciphers.
-ArrayList<String> ciphers = new ArrayList<String>(
-    Arrays.asList(params.getCipherSuites()));
-ciphers.retainAll(Arrays.asList(
-    "TLS_RSA_WITH_AES_128_CBC_SHA256",
-    "TLS_RSA_WITH_AES_256_CBC_SHA256",
-    "TLS_RSA_WITH_AES_256_CBC_SHA",
-    "TLS_RSA_WITH_AES_128_CBC_SHA",
-    "SSL_RSA_WITH_3DES_EDE_CBC_SHA",
-    "SSL_RSA_WITH_RC4_128_SHA1",
-    "SSL_RSA_WITH_RC4_128_MD5",
-    "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"));
-params.setCipherSuites(ciphers.toArray(new String[ciphers.size()]));
-

- As initialized above, the parameter object does not yet require host name checking. This has to be enabled separately, and this is only supported by OpenJDK 7 and later: - 
-params.setEndpointIdentificationAlgorithm("HTTPS");
-
- All application protocols can use the "HTTPS" algorithm. (The algorithms have minor differences with regard to wildcard handling, which should not matter in practice.) -
- Example 12.17, “Establishing a TLS connection with OpenJDK” shows how to establish the connection. Before the handshake is initialized, the protocol and cipher configuration has to be performed, by applying the parameter object params. (After this point, changes to params will not affect this TLS socket.) As mentioned initially, host name checking requires using an internal API on OpenJDK 6. -
Example 12.17. Establishing a TLS connection with OpenJDK
-// Create the socket and connect it at the TCP layer.
-SSLSocket socket = (SSLSocket) ctx.getSocketFactory()
-    .createSocket(host, port);
-
-// Disable the Nagle algorithm.
-socket.setTcpNoDelay(true);
-
-// Adjust ciphers and protocols.
-socket.setSSLParameters(params);
-
-// Perform the handshake.
-socket.startHandshake();
-
-// Validate the host name.  The match() method throws
-// CertificateException on failure.
-X509Certificate peer = (X509Certificate)
-    socket.getSession().getPeerCertificates()[0];
-// This is the only way to perform host name checking on OpenJDK 6.
-HostnameChecker.getInstance(HostnameChecker.TYPE_TLS).match(
-    host, peer);
-

- Starting with OpenJDK 7, the last lines can be omitted, provided that host name verification has been enabled by calling the setEndpointIdentificationAlgorithm method on the params object (before it was applied to the socket). -
- The TLS socket can be used as a regular socket, as shown in Example 12.18, “Using a TLS client socket in OpenJDK”. -
Example 12.18. Using a TLS client socket in OpenJDK
-socket.getOutputStream().write("GET / HTTP/1.0\r\n\r\n"
-    .getBytes(Charset.forName("UTF-8")));
-byte[] buffer = new byte[4096];
-int count = socket.getInputStream().read(buffer);
-System.out.write(buffer, 0, count);
-

12.2.3.1. Overriding server certificate validation with OpenJDK 6

- Overriding certificate validation requires a custom trust manager. With OpenJDK 6, the trust manager lacks information about the TLS session, and to which server the connection is made. Certificate overrides have to be tied to specific servers (host names). Consequently, different TrustManager and SSLContext objects have to be used for different servers. -
- In the trust manager shown in Example 12.19, “A customer trust manager for OpenJDK TLS clients”, the server certificate is identified by its SHA-256 hash. -
Example 12.19. A customer trust manager for OpenJDK TLS clients
-public class MyTrustManager implements X509TrustManager {
-    private final byte[] certHash;
-
-    public MyTrustManager(byte[] certHash) throws Exception {
-        this.certHash = certHash;
-    }
-
-    @Override
-    public void checkClientTrusted(X509Certificate[] chain, String authType)
-            throws CertificateException {
-        throw new UnsupportedOperationException();
-    }
-
-    @Override
-    public void checkServerTrusted(X509Certificate[] chain,
-            String authType) throws CertificateException {
-        byte[] digest = getCertificateDigest(chain[0]);
-        String digestHex = formatHex(digest);
-
-        if (Arrays.equals(digest, certHash)) {
-            System.err.println("info: accepting certificate: " + digestHex);
-        } else {
-            throw new CertificateException("certificate rejected: "  +
-                    digestHex);
-        }
-    }
-
-    @Override
-    public X509Certificate[] getAcceptedIssuers() {
-        return new X509Certificate[0];
-    }
-}
-

- This trust manager has to be passed to the init method of the SSLContext object, as show in Example 12.20, “Using a custom TLS trust manager with OpenJDK”. -
Example 12.20. Using a custom TLS trust manager with OpenJDK
-SSLContext ctx;
-try {
-    ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE");
-} catch (NoSuchAlgorithmException e) {
-    try {
-        ctx = SSLContext.getInstance("TLSv1", "SunJSSE");
-    } catch (NoSuchAlgorithmException e1) {
-        throw new AssertionError(e1);
-    } catch (NoSuchProviderException e1) {
-        throw new AssertionError(e1);
-    }
-} catch (NoSuchProviderException e) {
-    throw new AssertionError(e);
-}
-MyTrustManager tm = new MyTrustManager(certHash);
-ctx.init(null, new TrustManager[] {tm}, null);
-

- When certificate overrides are in place, host name verification should not be performed because there is no security requirement that the host name in the certificate matches the host name used to establish the connection (and it often will not). However, without host name verification, it is not possible to perform transparent fallback to certification validation using the system certificate store. -
- The approach described above works with OpenJDK 6 and later versions. Starting with OpenJDK 7, it is possible to use a custom subclass of the javax.net.ssl.X509ExtendedTrustManager class. The OpenJDK TLS implementation will call the new methods, passing along TLS session information. This can be used to implement certificate overrides as a fallback (if certificate or host name verification fails), and a trust manager object can be used for multiple servers because the server address is available to the trust manager. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-Python.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-Python.html deleted file mode 100644 index e54eca2..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client-Python.html +++ /dev/null @@ -1,62 +0,0 @@ - -12.2.5. Implementing TLS Clients With Python

Product SiteDocumentation Site

12.2.5. Implementing TLS Clients With Python

- The Python distribution provides a TLS implementation in the ssl module (actually a wrapper around OpenSSL). The exported interface is somewhat restricted, so that the client code shown below does not fully implement the recommendations in Section 12.1.1, “OpenSSL Pitfalls”. -

Important

- Currently, most Python function which accept https:// URLs or otherwise implement HTTPS support do not perform certificate validation at all. (For example, this is true for the httplib and xmlrpclib modules.) If you use HTTPS, you should not use the built-in HTTP clients. The Curl class in the curl module, as provided by the python-pycurl package implements proper certificate validation. -
- The ssl module currently does not perform host name checking on the server certificate. Example 12.26, “Implementing TLS host name checking Python (without wildcard support)” shows how to implement certificate matching, using the parsed certificate returned by getpeercert. -
Example 12.26. Implementing TLS host name checking Python (without wildcard support)
-def check_host_name(peercert, name):
-    """Simple certificate/host name checker.  Returns True if the
-    certificate matches, False otherwise.  Does not support
-    wildcards."""
-    # Check that the peer has supplied a certificate.
-    # None/{} is not acceptable.
-    if not peercert:
-        return False
-    if peercert.has_key("subjectAltName"):
-        for typ, val in peercert["subjectAltName"]:
-            if typ == "DNS" and val == name:
-                return True
-    else:
-        # Only check the subject DN if there is no subject alternative
-        # name.
-        cn = None
-        for attr, val in peercert["subject"]:
-            # Use most-specific (last) commonName attribute.
-            if attr == "commonName":
-                cn = val
-        if cn is not None:
-            return cn == name
-    return False
-

- To turn a regular, connected TCP socket into a TLS-enabled socket, use the ssl.wrap_socket function. The function call in Example 12.27, “Establishing a TLS client connection with Python” provides additional arguments to override questionable defaults in OpenSSL and in the Python module. -
  • - ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5" selects relatively strong cipher suites with certificate-based authentication. (The call to check_host_name function provides additional protection against anonymous cipher suites.) -
  • - ssl_version=ssl.PROTOCOL_TLSv1 disables SSL 2.0 support. By default, the ssl module sends an SSL 2.0 client hello, which is rejected by some servers. Ideally, we would request OpenSSL to negotiated the most recent TLS version supported by the server and the client, but the Python module does not allow this. -
  • - cert_reqs=ssl.CERT_REQUIRED turns on certificate validation. -
  • - ca_certs='/etc/ssl/certs/ca-bundle.crt' initializes the certificate store with a set of trusted root CAs. Unfortunately, it is necessary to hard-code this path into applications because the default path in OpenSSL is not available through the Python ssl module. -
- The ssl module (and OpenSSL) perform certificate validation, but the certificate must be compared manually against the host name, by calling the check_host_name defined above. -
Example 12.27. Establishing a TLS client connection with Python
-sock = ssl.wrap_socket(sock,
-                       ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5",
-                       ssl_version=ssl.PROTOCOL_TLSv1,
-                       cert_reqs=ssl.CERT_REQUIRED,
-                       ca_certs='/etc/ssl/certs/ca-bundle.crt')
-# getpeercert() triggers the handshake as a side effect.
-if not check_host_name(sock.getpeercert(), host):
-    raise IOError("peer certificate does not match host name")
-

- After the connection has been established, the TLS socket can be used like a regular socket: - 
-sock.write("GET / HTTP/1.1\r\nHost: " + host + "\r\n\r\n")
-print sock.read()
-
- Closing the TLS socket is straightforward as well: - 
-sock.close()
-
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client.html deleted file mode 100644 index b8f4ac1..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-TLS-Client.html +++ /dev/null @@ -1,199 +0,0 @@ - -12.2. TLS Clients

Product SiteDocumentation Site

12.2. TLS Clients

- Secure use of TLS in a client generally involves all of the following steps. (Individual instructions for specific TLS implementations follow in the next sections.) -
  • - The client must configure the TLS library to use a set of trusted root certificates. These certificates are provided by the system in /etc/ssl/certs or files derived from it. -
  • - The client selects sufficiently strong cryptographic primitives and disables insecure ones (such as no-op encryption). Compression and SSL version 2 support must be disabled (including the SSLv2-compatible handshake). -
  • - The client initiates the TLS connection. The Server Name Indication extension should be used if supported by the TLS implementation. Before switching to the encrypted connection state, the contents of all input and output buffers must be discarded. -
  • - The client needs to validate the peer certificate provided by the server, that is, the client must check that there is a cryptographically protected chain from a trusted root certificate to the peer certificate. (Depending on the TLS implementation, a TLS handshake can succeed even if the certificate cannot be validated.) -
  • - The client must check that the configured or user-provided server name matches the peer certificate provided by the server. -
- It is safe to provide users detailed diagnostics on certificate validation failures. Other causes of handshake failures and, generally speaking, any details on other errors reported by the TLS implementation (particularly exception tracebacks), must not be divulged in ways that make them accessible to potential attackers. Otherwise, it is possible to create decryption oracles. -

Important

- Depending on the application, revocation checking (against certificate revocations lists or via OCSP) and session resumption are important aspects of production-quality client. These aspects are not yet covered. -

12.2.1. Implementation TLS Clients With OpenSSL

- In the following code, the error handling is only exploratory. Proper error handling is required for production use, especially in libraries. -
- The OpenSSL library needs explicit initialization (see Example 12.3, “OpenSSL library initialization”). -
Example 12.3. OpenSSL library initialization
-// The following call prints an error message and calls exit() if
-// the OpenSSL configuration file is unreadable.
-OPENSSL_config(NULL);
-// Provide human-readable error messages.
-SSL_load_error_strings();
-// Register ciphers.
-SSL_library_init();
-

- After that, a context object has to be created, which acts as a factory for connection objects (Example 12.4, “OpenSSL client context creation”). We use an explicit cipher list so that we do not pick up any strange ciphers when OpenSSL is upgraded. The actual version requested in the client hello depends on additional restrictions in the OpenSSL library. If possible, you should follow the example code and use the default list of trusted root certificate authorities provided by the system because you would have to maintain your own set otherwise, which can be cumbersome. -
Example 12.4. OpenSSL client context creation
-// Configure a client connection context.  Send a hendshake for the
-// highest supported TLS version, and disable compression.
-const SSL_METHOD *const req_method = SSLv23_client_method();
-SSL_CTX *const ctx = SSL_CTX_new(req_method);
-if (ctx == NULL) {
-  ERR_print_errors(bio_err);
-  exit(1);
-}
-SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_COMPRESSION);
-
-// Adjust the ciphers list based on a whitelist.  First enable all
-// ciphers of at least medium strength, to get the list which is
-// compiled into OpenSSL.
-if (SSL_CTX_set_cipher_list(ctx, "HIGH:MEDIUM") != 1) {
-  ERR_print_errors(bio_err);
-  exit(1);
-}
-{
-  // Create a dummy SSL session to obtain the cipher list.
-  SSL *ssl = SSL_new(ctx);
-  if (ssl == NULL) {
-    ERR_print_errors(bio_err);
-    exit(1);
-  }
-  STACK_OF(SSL_CIPHER) *active_ciphers = SSL_get_ciphers(ssl);
-  if (active_ciphers == NULL) {
-    ERR_print_errors(bio_err);
-    exit(1);
-  }
-  // Whitelist of candidate ciphers.
-  static const char *const candidates[] =  {
-    "AES128-GCM-SHA256", "AES128-SHA256", "AES256-SHA256", // strong ciphers
-    "AES128-SHA", "AES256-SHA", // strong ciphers, also in older versions
-    "RC4-SHA", "RC4-MD5", // backwards compatibility, supposed to be weak
-    "DES-CBC3-SHA", "DES-CBC3-MD5", // more backwards compatibility
-    NULL
-  };
-  // Actually selected ciphers.
-  char ciphers[300];
-  ciphers[0] = '\0';
-  for (const char *const *c = candidates; *c; ++c) {
-    for (int i = 0; i < sk_SSL_CIPHER_num(active_ciphers); ++i) {
-	if (strcmp(SSL_CIPHER_get_name(sk_SSL_CIPHER_value(active_ciphers, i)),
-		   *c) == 0) {
-	  if (*ciphers) {
-	    strcat(ciphers, ":");
-	  }
-	  strcat(ciphers, *c);
-	  break;
-	}
-    }
-  }
-  SSL_free(ssl);
-  // Apply final cipher list.
-  if (SSL_CTX_set_cipher_list(ctx, ciphers) != 1) {
-    ERR_print_errors(bio_err);
-    exit(1);
-  }
-}
-
-// Load the set of trusted root certificates.
-if (!SSL_CTX_set_default_verify_paths(ctx)) {
-  ERR_print_errors(bio_err);
-  exit(1);
-}
-

- A single context object can be used to create multiple connection objects. It is safe to use the same SSL_CTX object for creating connections concurrently from multiple threads, provided that the SSL_CTX object is not modified (e.g., callbacks must not be changed). -
- After creating the TCP socket and disabling the Nagle algorithm (per Example 12.1, “Deactivating the TCP Nagle algorithm”), the actual connection object needs to be created, as show in Example 12.4, “OpenSSL client context creation”. If the handshake started by SSL_connect fails, the ssl_print_error_and_exit function from Example 12.2, “Obtaining OpenSSL error codes” is called. -
- The certificate_validity_override function provides an opportunity to override the validity of the certificate in case the OpenSSL check fails. If such functionality is not required, the call can be removed, otherwise, the application developer has to implement it. -
- The host name passed to the functions SSL_set_tlsext_host_name and X509_check_host must be the name that was passed to getaddrinfo or a similar name resolution function. No host name canonicalization must be performed. The X509_check_host function used in the final step for host name matching is currently only implemented in OpenSSL 1.1, which is not released yet. In case host name matching fails, the function certificate_host_name_override is called. This function should check user-specific certificate store, to allow a connection even if the host name does not match the certificate. This function has to be provided by the application developer. Note that the override must be keyed by both the certificate and the host name. -
Example 12.5. Creating a client connection using OpenSSL
-// Create the connection object.
-SSL *ssl = SSL_new(ctx);
-if (ssl == NULL) {
-  ERR_print_errors(bio_err);
-  exit(1);
-}
-SSL_set_fd(ssl, sockfd);
-
-// Enable the ServerNameIndication extension
-if (!SSL_set_tlsext_host_name(ssl, host)) {
-  ERR_print_errors(bio_err);
-  exit(1);
-}
-
-// Perform the TLS handshake with the server.
-ret = SSL_connect(ssl);
-if (ret != 1) {
-  // Error status can be 0 or negative.
-  ssl_print_error_and_exit(ssl, "SSL_connect", ret);
-}
-
-// Obtain the server certificate.
-X509 *peercert = SSL_get_peer_certificate(ssl);
-if (peercert == NULL) {
-  fprintf(stderr, "peer certificate missing");
-  exit(1);
-}
-
-// Check the certificate verification result.  Allow an explicit
-// certificate validation override in case verification fails.
-int verifystatus = SSL_get_verify_result(ssl);
-if (verifystatus != X509_V_OK && !certificate_validity_override(peercert)) {
-  fprintf(stderr, "SSL_connect: verify result: %s\n",
-	    X509_verify_cert_error_string(verifystatus));
-  exit(1);
-}
-
-// Check if the server certificate matches the host name used to
-// establish the connection.
-// FIXME: Currently needs OpenSSL 1.1.
-if (X509_check_host(peercert, (const unsigned char *)host, strlen(host),
-		      0) != 1
-    && !certificate_host_name_override(peercert, host)) {
-  fprintf(stderr, "SSL certificate does not match host name\n");
-  exit(1);
-}
-
-X509_free(peercert);
-
-

- The connection object can be used for sending and receiving data, as in Example 12.6, “Using an OpenSSL connection to send and receive data”. It is also possible to create a BIO object and use the SSL object as the underlying transport, using BIO_set_ssl. -
Example 12.6. Using an OpenSSL connection to send and receive data
-const char *const req = "GET / HTTP/1.0\r\n\r\n";
-if (SSL_write(ssl, req, strlen(req)) < 0) {
-  ssl_print_error_and_exit(ssl, "SSL_write", ret);
-}
-char buf[4096];
-ret = SSL_read(ssl, buf, sizeof(buf));
-if (ret < 0) {
-  ssl_print_error_and_exit(ssl, "SSL_read", ret);
-}
-

- When it is time to close the connection, the SSL_shutdown function needs to be called twice for an orderly, synchronous connection termination (Example 12.7, “Closing an OpenSSL connection in an orderly fashion”). This exchanges close_notify alerts with the server. The additional logic is required to deal with an unexpected close_notify from the server. Note that is necessary to explicitly close the underlying socket after the connection object has been freed. -
Example 12.7. Closing an OpenSSL connection in an orderly fashion
-// Send the close_notify alert.
-ret = SSL_shutdown(ssl);
-switch (ret) {
-case 1:
-  // A close_notify alert has already been received.
-  break;
-case 0:
-  // Wait for the close_notify alert from the peer.
-  ret = SSL_shutdown(ssl);
-  switch (ret) {
-  case 0:
-    fprintf(stderr, "info: second SSL_shutdown returned zero\n");
-    break;
-  case 1:
-    break;
-  default:
-    ssl_print_error_and_exit(ssl, "SSL_shutdown 2", ret);
-  }
-  break;
-default:
-  ssl_print_error_and_exit(ssl, "SSL_shutdown 1", ret);
-}
-SSL_free(ssl);
-close(sockfd);
-

- Example 12.8, “Closing an OpenSSL connection in an orderly fashion” shows how to deallocate the context object when it is no longer needed because no further TLS connections will be established. -
Example 12.8. Closing an OpenSSL connection in an orderly fashion
-SSL_CTX_free(ctx);
-

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors-Child_Processes.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors-Child_Processes.html deleted file mode 100644 index 26fd42d..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors-Child_Processes.html +++ /dev/null @@ -1,18 +0,0 @@ - -5.2. Preventing file descriptor leaks to child processes

Product SiteDocumentation Site

5.2. Preventing file descriptor leaks to child processes

- Child processes created with fork share the initial set of file descriptors with their parent process. By default, file descriptors are also preserved if a new process image is created with execve (or any of the other functions such as system or posix_spawn). -
- Usually, this behavior is not desirable. There are two ways to turn it off, that is, to prevent new process images from inheriting the file descriptors in the parent process: -
  • - Set the close-on-exec flag on all newly created file descriptors. Traditionally, this flag is controlled by the FD_CLOEXEC flag, using F_GETFD and F_SETFD operations of the fcntl function. -
    - However, in a multi-threaded process, there is a race condition: a subprocess could have been created between the time the descriptor was created and the FD_CLOEXEC was set. Therefore, many system calls which create descriptors (such as open and openat) now accept the O_CLOEXEC flag (SOCK_CLOEXEC for socket and socketpair), which cause the FD_CLOEXEC flag to be set for the file descriptor in an atomic fashion. In addition, a few new systems calls were introduced, such as pipe2 and dup3. -
    - The downside of this approach is that every descriptor needs to receive special treatment at the time of creation, otherwise it is not completely effective. -
  • - After calling fork, but before creating a new process image with execve, all file descriptors which the child process will not need are closed. -
    - Traditionally, this was implemented as a loop over file descriptors ranging from 3 to 255 and later 1023. But this is only an approximatio because it is possible to create file descriptors outside this range easily (see Section 5.3, “Dealing with the select limit”). Another approach reads /proc/self/fd and closes the unexpected descriptors listed there, but this approach is much slower. -
- At present, environments which care about file descriptor leakage implement the second approach. OpenJDK 6 and 7 are among them. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors-Limit.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors-Limit.html deleted file mode 100644 index 8a4667a..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors-Limit.html +++ /dev/null @@ -1,22 +0,0 @@ - -5.3. Dealing with the select limit

Product SiteDocumentation Site

5.3. Dealing with the select limit

- By default, a user is allowed to open only 1024 files in a single process, but the system administrator can easily change this limit (which is necessary for busy network servers). However, there is another restriction which is more difficult to overcome. -
- The select function only supports a maximum of FD_SETSIZE file descriptors (that is, the maximum permitted value for a file descriptor is FD_SETSIZE - 1, usually 1023.) If a process opens many files, descriptors may exceed such limits. It is impossible to query such descriptors using select. -
- If a library which creates many file descriptors is used in the same process as a library which uses select, at least one of them needs to be changed. Calls to select can be replaced with calls to poll or another event handling mechanism. -
- Alternatively, the library with high descriptor usage can relocate descriptors above the FD_SETSIZE limit using the following procedure. -
  • - Create the file descriptor fd as usual, preferably with the O_CLOEXEC flag. -
  • - Before doing anything else with the descriptor fd, invoke: - 
    -	  int newfd = fcntl(fd, F_DUPFD_CLOEXEC, (long)FD_SETSIZE);
-
  • - Check that newfd result is non-negative, otherwise close fd and report an error, and return. -
  • - Close fd and continue to use newfd. -
- The new descriptor has been allocated above the FD_SETSIZE. Even though this algorithm is racy in the sense that the FD_SETSIZE first descriptors could fill up, a very high degree of physical parallelism is required before this becomes a problem. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors.html deleted file mode 100644 index 6abfdc8..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Descriptors.html +++ /dev/null @@ -1,26 +0,0 @@ - -Chapter 5. File Descriptor Management

Product SiteDocumentation Site

Chapter 5. File Descriptor Management

5.1. Closing descriptors
5.1.1. Error handling during descriptor close
5.1.2. Closing descriptors and race conditions
5.1.3. Lingering state after close
5.2. Preventing file descriptor leaks to child processes
5.3. Dealing with the select limit
- File descriptors underlie all input/output mechanisms offered by the system. They are used to implementation the FILE *-based functions found in <stdio.h>, and all the file and network communication facilities provided by the Python and Java environments are eventually implemented in them. -
- File descriptors are small, non-negative integers in userspace, and are backed on the kernel side with complicated data structures which can sometimes grow very large. -

5.1. Closing descriptors

- If a descriptor is no longer used by a program and is not closed explicitly, its number cannot be reused (which is problematic in itself, see Section 5.3, “Dealing with the select limit”), and the kernel resources are not freed. Therefore, it is important to close all descriptors at the earlierst point in time possible, but not earlier. -

5.1.1. Error handling during descriptor close

- The close system call is always successful in the sense that the passed file descriptor is never valid after the function has been called. However, close still can return an error, for example if there was a file system failure. But this error is not very useful because the absence of an error does not mean that all caches have been emptied and previous writes have been made durable. Programs which need such guarantees must open files with O_SYNC or use fsync or fdatasync, and may also have to fsync the directory containing the file. -

5.1.2. Closing descriptors and race conditions

- Unlike process IDs, which are recycle only gradually, the kernel always allocates the lowest unused file descriptor when a new descriptor is created. This means that in a multi-threaded program which constantly opens and closes file descriptors, descriptors are reused very quickly. Unless descriptor closing and other operations on the same file descriptor are synchronized (typically, using a mutex), there will be race coniditons and I/O operations will be applied to the wrong file descriptor. -
- Sometimes, it is necessary to close a file descriptor concurrently, while another thread might be about to use it in a system call. In order to support this, a program needs to create a single special file descriptor, one on which all I/O operations fail. One way to achieve this is to use socketpair, close one of the descriptors, and call shutdown(fd, SHUTRDWR) on the other. -
- When a descriptor is closed concurrently, the program does not call close on the descriptor. Instead it program uses dup2 to replace the descriptor to be closed with the dummy descriptor created earlier. This way, the kernel will not reuse the descriptor, but it will carry out all other steps associated with calling a descriptor (for instance, if the descriptor refers to a stream socket, the peer will be notified). -
- This is just a sketch, and many details are missing. Additional data structures are needed to determine when it is safe to really close the descriptor, and proper locking is required for that. -

5.1.3. Lingering state after close

- By default, closing a stream socket returns immediately, and the kernel will try to send the data in the background. This means that it is impossible to implement accurate accounting of network-related resource utilization from userspace. -
- The SO_LINGER socket option alters the behavior of close, so that it will return only after the lingering data has been processed, either by sending it to the peer successfully, or by discarding it after the configured timeout. However, there is no interface which could perform this operation in the background, so a separate userspace thread is needed for each close call, causing scalability issues. -
- Currently, there is no application-level countermeasure which applies universally. Mitigation is possible with iptables (the connlimit match type in particular) and specialized filtering devices for denial-of-service network traffic. -
- These problems are not related to the TIME_WAIT state commonly seen in netstat output. The kernel automatically expires such sockets if necessary. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Features.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Features.html deleted file mode 100644 index 2bd8def..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Features.html +++ /dev/null @@ -1,28 +0,0 @@ - -6.4. File system features

Product SiteDocumentation Site

6.4. File system features

- Not all file systems support all features. This makes it very difficult to write general-purpose tools for copying files. For example, a copy operation intending to preserve file permissions will generally fail when copying to a FAT file system. -
  • - Some file systems are case-insensitive. Most should be case-preserving, though. -
  • - Name length limits vary greatly, from eight to thousands of bytes. Path length limits differ as well. Most systems impose an upper bound on path names passed to the kernel, but using relative path names, it is possible to create and access files whose absolute path name is essentially of unbounded length. -
  • - Some file systems do not store names as fairly unrestricted byte sequences, as it has been traditionally the case on GNU systems. This means that some byte sequences (outside the POSIX safe character set) are not valid names. Conversely, names of existing files may not be representable as byte sequences, and the files are thus inaccessible on GNU systems. Some file systems perform Unicode canonicalization on file names. These file systems preserve case, but reading the name of a just-created file using readdir might still result in a different byte sequence. -
  • - Permissions and owners are not universally supported (and SUID/SGID bits may not be available). For example, FAT file systems assign ownership based on a mount option, and generally mark all files as executable. Any attempt to change permissions would result in an error. -
  • - Non-regular files (device nodes, FIFOs) are not generally available. -
  • - Only on some file systems, files can have holes, that is, not all of their contents is backed by disk storage. -
  • - ioctl support (even fairly generic functionality such as FIEMAP for discovering physical file layout and holes) is file-system-specific. -
  • - Not all file systems support extended attributes, ACLs and SELinux metadata. Size and naming restriction on extended attributes vary. -
  • - Hard links may not be supported at all (FAT) or only within the same directory (AFS). Symbolic links may not be available, either. Reflinks (hard links with copy-on-write semantics) are still very rare. Recent systems restrict creation of hard links to users which own the target file or have read/write access to it, but older systems do not. -
  • - Renaming (or moving) files using rename can fail (even when stat indicates that the source and target directories are located on the same file system). This system call should work if the old and new paths are located in the same directory, though. -
  • - Locking semantics vary among file systems. This affects advisory and mandatory locks. For example, some network file systems do not allow deleting files which are opened by any process. -
  • - Resolution of time stamps varies from two seconds to nanoseconds. Not all time stamps are available on all file systems. File creation time (birth time) is not exposed over the stat/fstat interface, even if stored by the file system. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Foreign.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Foreign.html deleted file mode 100644 index 2d9adeb..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Foreign.html +++ /dev/null @@ -1,10 +0,0 @@ - -6.2. Accessing the file system as a different user

Product SiteDocumentation Site

6.2. Accessing the file system as a different user

- This section deals with access to the file system as a specific user. This is different from accessing files and directories owned by a different, potentially untrusted user; see Section 6.2, “Accessing the file system as a different user”. -
- One approach is to spawn a child process which runs under the target user and group IDs (both effective and real IDs). Note that this child process can block indefinitely, even when processing regular files only. For example, a special FUSE file system could cause the process to hang in uninterruptible sleep inside a stat system call. -
- An existing process could change its user and group ID using setfsuid and setfsgid. (These functions are preferred over seteuid and setegid because they do not allow the impersonated user to send signals to the process.) These functions are not thread safe. In multi-threaded processes, these operations need to be performed in a single-threaded child process. Unexpected blocking may occur as well. -
- It is not recommended to try to reimplement the kernel permission checks in user space because the required checks are complex. It is also very difficult to avoid race conditions during path name resolution. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Free_Space.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Free_Space.html deleted file mode 100644 index 15c45c1..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Free_Space.html +++ /dev/null @@ -1,4 +0,0 @@ - -6.5. Checking free space

Product SiteDocumentation Site

6.5. Checking free space

- The statvfs and fstatvfs functions allow programs to examine the number of available blocks and inodes, through the members f_bfree, f_bavail, f_ffree, and f_favail of struct statvfs. Some file systems return fictional values in the f_ffree and f_favail fields, so the only reliable way to discover if the file system still has space for a file is to try to create it. The f_bfree field should be reasonably accurate, though. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Limits.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Limits.html deleted file mode 100644 index f9788df..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-File_System-Limits.html +++ /dev/null @@ -1,6 +0,0 @@ - -6.3. File system limits

Product SiteDocumentation Site

6.3. File system limits

- For historical reasons, there are preprocessor constants such as PATH_MAX, NAME_MAX. However, on most systems, the length of canonical path names (absolute path names with all symbolic links resolved, as returned by realpath or canonicalize_file_name) can exceed PATH_MAX bytes, and individual file name components can be longer than NAME_MAX. This is also true of the _PC_PATH_MAX and _PC_NAME_MAX values returned by pathconf, and the f_namemax member of struct statvfs. Therefore, these constants should not be used. This is also reason why the readdir_r should never be used (instead, use readdir). -
- You should not write code in a way that assumes that there is an upper limit on the number of subdirectories of a directory, the number of regular files in a directory, or the link count of an inode. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Library_Design-Callbacks.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Library_Design-Callbacks.html deleted file mode 100644 index d79bc76..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Library_Design-Callbacks.html +++ /dev/null @@ -1,14 +0,0 @@ - -4.3. Callbacks

Product SiteDocumentation Site

4.3. Callbacks

- Higher-order code is difficult to analyze for humans and computers alike, so it should be avoided. Often, an iterator-based interface (a library function which is called repeatedly by client code and returns a stream of events) leads to a better design which is easier to document and use. -
- If callbacks are unavoidable, some guidelines for them follow. -
- In modern C++ code, std::function objects should be used for callbacks. -
- In older C++ code and in C code, all callbacks must have an additional closure parameter of type void *, the value of which can be specified by client code. If possible, the value of the closure parameter should be provided by client code at the same time a specific callback is registered (or specified as a function argument). If a single closure parameter is shared by multiple callbacks, flexibility is greatly reduced, and conflicts between different pieces of client code using the same library object could be unresolvable. In some cases, it makes sense to provide a de-registration callback which can be used to destroy the closure parameter when the callback is no longer used. -
- Callbacks can throw exceptions or call longjmp. If possible, all library objects should remain in a valid state. (All further operations on them can fail, but it should be possible to deallocate them without causing resource leaks.) -
- The presence of callbacks raises the question if functions provided by the library are reentrant. Unless a library was designed for such use, bad things will happen if a callback function uses functions in the same library (particularly if they are invoked on the same objects and manipulate the same state). When the callback is invoked, the library can be in an inconsistent state. Reentrant functions are more difficult to write than thread-safe functions (by definition, simple locking would immediately lead to deadlocks). It is also difficult to decide what to do when destruction of an object which is currently processing a callback is requested. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes-Daemons.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes-Daemons.html deleted file mode 100644 index 7db21c7..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes-Daemons.html +++ /dev/null @@ -1,18 +0,0 @@ - -8.4. Daemons

Product SiteDocumentation Site

8.4. Daemons

- Background processes providing system services (daemons) need to decouple themselves from the controlling terminal and the parent process environment: -
  • - Fork. -
  • - In the child process, call setsid. The parent process can simply exit (using _exit, to avoid running clean-up actions twice). -
  • - In the child process, fork again. Processing continues in the child process. Again, the parent process should just exit. -
  • - Replace the descriptors 0, 1, 2 with a descriptor for /dev/null. Logging should be redirected to syslog. -
- Older instructions for creating daemon processes recommended a call to umask(0). This is risky because it often leads to world-writable files and directories, resulting in security vulnerabilities such as arbitrary process termination by untrusted local users, or log file truncation. If the umask needs setting, a restrictive value such as 027 or 077 is recommended. -
- Other aspects of the process environment may have to changed as well (environment variables, signal handler disposition). -
- It is increasingly common that server processes do not run as background processes, but as regular foreground process under a supervising master process (such as systemd). Server processes should offer a command line option which disables forking and replacement of the standard output and standard error streams. Such an option is also useful for debugging. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes-Fork-Parallel.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes-Fork-Parallel.html deleted file mode 100644 index e184d1f..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes-Fork-Parallel.html +++ /dev/null @@ -1,4 +0,0 @@ - -8.6. fork as a primitive for parallelism

Product SiteDocumentation Site

8.6. fork as a primitive for parallelism

- A call to fork which is not immediately followed by a call to execve (perhaps after rearranging and closing file descriptors) is typically unsafe, especially from a library which does not control the state of the entire process. Such use of fork should be replaced with proper child processes or threads. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes.html deleted file mode 100644 index 435ba94..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Processes.html +++ /dev/null @@ -1,56 +0,0 @@ - -Chapter 8. Processes

Product SiteDocumentation Site

Chapter 8. Processes

8.1. Safe process creation
8.1.1. Obtaining the program path and the command line template
8.1.2. Bypassing the shell
8.1.3. Specifying the process environment
8.1.4. Robust argument list processing
8.1.5. Passing secrets to subprocesses
8.2. Handling child process termination
8.3. SUID/SGID processes
8.3.1. Accessing environment variables
8.4. Daemons
8.5. Semantics of command line arguments
8.6. fork as a primitive for parallelism

8.1. Safe process creation

- This section describes how to create new child processes in a safe manner. In addition to the concerns addressed below, there is the possibility of file descriptor leaks, see Section 5.2, “Preventing file descriptor leaks to child processes”. -

8.1.1. Obtaining the program path and the command line template

- The name and path to the program being invoked should be hard-coded or controlled by a static configuration file stored at a fixed location (at an file system absolute path). The same applies to the template for generating the command line. -
- The configured program name should be an absolute path. If it is a relative path, the contents of the PATH must be obtained in s secure manner (see Section 8.3.1, “Accessing environment variables”). If the PATH variable is not set or untrusted, the safe default /bin:/usr/bin must be used. -
- If too much flexibility is provided here, it may allow invocation of arbitrary programs without proper authorization. -

8.1.2. Bypassing the shell

- Child processes should be created without involving the system shell. -
- For C/C++, system should not be used. The posix_spawn function can be used instead, or a combination fork and execve. (In some cases, it may be preferable to use vfork or the Linux-specific clone system call instead of fork.) -
- In Python, the subprocess module bypasses the shell by default (when the shell keyword argument is not set to true). os.system should not be used. -
- The Java class java.lang.ProcessBuilder can be used to create subprocesses without interference from the system shell. -

Portability notice

- On Windows, there is no argument vector, only a single argument string. Each application is responsible for parsing this string into an argument vector. There is considerable variance among the quoting style recognized by applications. Some of them expand shell wildcards, others do not. Extensive application-specific testing is required to make this secure. -
- Note that some common applications (notably ssh) unconditionally introduce the use of a shell, even if invoked directly without a shell. It is difficult to use these applications in a secure manner. In this case, untrusted data should be supplied by other means. For example, standard input could be used, instead of the command line. -

8.1.3. Specifying the process environment

- Child processes should be created with a minimal set of environment variables. This is absolutely essential if there is a trust transition involved, either when the parent process was created, or during the creation of the child process. -
- In C/C++, the environment should be constructed as an array of strings and passed as the envp argument to posix_spawn or execve. The functions setenv, unsetenv and putenv should not be used. They are not thread-safe and suffer from memory leaks. -
- Python programs need to specify a dict for the the env argument of the subprocess.Popen constructor. The Java class java.lang.ProcessBuilder provides a environment() method, which returns a map that can be manipulated. -
- The following list provides guidelines for selecting the set of environment variables passed to the child process. -
  • - PATH should be initialized to /bin:/usr/bin. -
  • - USER and HOME can be inhereted from the parent process environment, or they can be initialized from the pwent structure for the user. -
  • - The DISPLAY and XAUTHORITY variables should be passed to the subprocess if it is an X program. Note that this will typically not work across trust boundaries because XAUTHORITY refers to a file with 0600 permissions. -
  • - The location-related environment variables LANG, LANGUAGE, LC_ADDRESS, LC_ALL, LC_COLLATE, LC_CTYPE, LC_IDENTIFICATION, LC_MEASUREMENT, LC_MESSAGES, LC_MONETARY, LC_NAME, LC_NUMERIC, LC_PAPER, LC_TELEPHONE and LC_TIME can be passed to the subprocess if present. -
  • - The called process may need application-specific environment variables, for example for passing passwords. (See Section 8.1.5, “Passing secrets to subprocesses”.) -
  • - All other environment variables should be dropped. Names for new environment variables should not be accepted from untrusted sources. -

8.1.4. Robust argument list processing

- When invoking a program, it is sometimes necessary to include data from untrusted sources. Such data should be check against embedded NUL characters because the system APIs will sliently truncate argument strings at the first NUL character. -
- The following recommendations assume that the program being invoked uses GNU-style option processing using getopt_long. This convention is widely used, but it is just that, and individual programs might interpret a command line in a different way. -
- If the untrusted data has to go into an option, use the --option-name=VALUE syntax, placing the option and its value into the same command line argument. This avoids any potential confusion if the data starts with -. -
- For positional arguments, terminate the option list with a single -- marker after the last option, and include the data at the right position. The -- marker terminates option processing, and the data will not be treated as an option even if it starts with a dash. -

8.1.5. Passing secrets to subprocesses

- The command line (the name of the program and its argument) of a running process is traditionally available to all local users. The called program can overwrite this information, but only after it has run for a bit of time, during which the information may have been read by other processes. However, on Linux, the process environment is restricted to the user who runs the process. Therefore, if you need a convenient way to pass a password to a child process, use an environment variable, and not a command line argument. (See Section 8.1.3, “Specifying the process environment”.) -

Portability notice

- On some UNIX-like systems (notably Solaris), environment variables can be read by any system user, just like command lines. -
- If the environment-based approach cannot be used due to portability concerns, the data can be passed on standard input. Some programs (notably gpg) use special file descriptors whose numbers are specified on the command line. Temporary files are an option as well, but they might give digital forensics access to sensitive data (such as passphrases) because it is difficult to safely delete them in all cases. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Entities.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Entities.html deleted file mode 100644 index 955c416..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Entities.html +++ /dev/null @@ -1,6 +0,0 @@ - -9.4.2. Entity expansion

Product SiteDocumentation Site

9.4.2. Entity expansion

- When external DTD processing is disabled, an internal DTD subset can still contain entity definitions. Entity declarations can reference other entities. Some XML libraries expand entities automatically, and this processing cannot be switched off in some places (such as attribute values or content models). Without limits on the entity nesting level, this expansion results in data which can grow exponentially in length with size of the input. (If there is a limit on the nesting level, the growth is still polynomial, unless further limits are imposed.) -
- Consequently, the processing internal DTD subsets should be disabled if possible, and only trusted DTDs should be processed. If a particular XML application does not permit such restrictions, then application-specific limits are called for. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Expat.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Expat.html deleted file mode 100644 index 9354658..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Expat.html +++ /dev/null @@ -1,31 +0,0 @@ - -9.4.5. Using Expat for XML parsing

Product SiteDocumentation Site

9.4.5. Using Expat for XML parsing

- By default, Expat does not try to resolve external IDs, so no steps are required to block them. However, internal entity declarations are processed. Installing a callback which stops parsing as soon as such entities are encountered disables them, see Example 9.1, “Disabling XML entity processing with Expat”. Expat does not perform any validation, so there are no problems related to that. -
Example 9.1. Disabling XML entity processing with Expat
-// Stop the parser when an entity declaration is encountered.
-static void
-EntityDeclHandler(void *userData,
-		  const XML_Char *entityName, int is_parameter_entity,
-		  const XML_Char *value, int value_length,
-		  const XML_Char *base, const XML_Char *systemId,
-		  const XML_Char *publicId, const XML_Char *notationName)
-{
-  XML_StopParser((XML_Parser)userData, XML_FALSE);
-}
-

- This handler must be installed when the XML_Parser object is created (Example 9.2, “Creating an Expat XML parser”). -
Example 9.2. Creating an Expat XML parser
-XML_Parser parser = XML_ParserCreate("UTF-8");
-if (parser == NULL) {
-  fprintf(stderr, "XML_ParserCreate failed\n");
-  close(fd);
-  exit(1);
-}
-// EntityDeclHandler needs a reference to the parser to stop
-// parsing.
-XML_SetUserData(parser, parser);
-// Disable entity processing, to inhibit entity expansion.
-XML_SetEntityDeclHandler(parser, EntityDeclHandler);
-

- It is also possible to reject internal DTD subsets altogeher, using a suitable XML_StartDoctypeDeclHandler handler installed with XML_SetDoctypeDeclHandler. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse-SAX.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse-SAX.html deleted file mode 100644 index 1fe7ed9..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse-SAX.html +++ /dev/null @@ -1,47 +0,0 @@ - -9.4.6.2. XML Schema validation in OpenJDK

Product SiteDocumentation Site

9.4.6.2. XML Schema validation in OpenJDK

- Example 9.7, “SAX-based validation against an XML schema in OpenJDK” shows how to validate a document against an XML Schema, using a SAX-based approach. The XML data is read from an java.io.InputStream in the inputStream variable. -
Example 9.7. SAX-based validation against an XML schema in OpenJDK
-SchemaFactory factory = SchemaFactory.newInstance(
-        XMLConstants.W3C_XML_SCHEMA_NS_URI);
-
-// This enables restrictions on the schema and document
-// complexity.
-factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
-
-// This prevents resource resolution by the schema itself.
-// If the schema is trusted and references additional files,
-// this line must be omitted, otherwise loading these files
-// will fail.
-factory.setResourceResolver(new NoResourceResolver());
-
-Schema schema = factory.newSchema(schemaFile);
-Validator validator = schema.newValidator();
-
-// This prevents external resource resolution.
-validator.setResourceResolver(new NoResourceResolver());
-
-validator.validate(new SAXSource(new InputSource(inputStream)));
-

- The NoResourceResolver class is defined in Example 9.4, “Helper class to prevent schema resolution in OpenJDK”. -
- If you need to validate a document against an XML schema, use the code in Example 9.6, “DOM-based XML parsing in OpenJDK” to create the document, but do not enable validation at this point. Then use Example 9.8, “Validation of a DOM document against an XML schema in OpenJDK” to perform the schema-based validation on the org.w3c.dom.Document instance document. -
Example 9.8. Validation of a DOM document against an XML schema in OpenJDK
-SchemaFactory factory = SchemaFactory.newInstance(
-        XMLConstants.W3C_XML_SCHEMA_NS_URI);
-
-// This enables restrictions on schema complexity.
-factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
-
-// The following line prevents resource resolution
-// by the schema itself.
-factory.setResourceResolver(new NoResourceResolver());
-
-Schema schema = factory.newSchema(schemaFile);
-
-Validator validator = schema.newValidator();
-
-// This prevents external resource resolution.
-validator.setResourceResolver(new NoResourceResolver());
-validator.validate(new DOMSource(document));
-

\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse.html deleted file mode 100644 index c0825be..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-OpenJDK_Parse.html +++ /dev/null @@ -1,74 +0,0 @@ - -9.4.6. Using OpenJDK for XML parsing and validation

Product SiteDocumentation Site

9.4.6. Using OpenJDK for XML parsing and validation

- OpenJDK contains facilities for DOM-based, SAX-based, and StAX-based document parsing. Documents can be validated against DTDs or XML schemas. -
- The approach taken to deal with entity expansion differs from the general recommendation in Section 9.4.2, “Entity expansion”. We enable the the feature flag javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, which enforces heuristic restrictions on the number of entity expansions. Note that this flag alone does not prevent resolution of external references (system IDs or public IDs), so it is slightly misnamed. -
- In the following sections, we use helper classes to prevent external ID resolution. -
Example 9.3. Helper class to prevent DTD external entity resolution in OpenJDK
-class NoEntityResolver implements EntityResolver {
-    @Override
-    public InputSource resolveEntity(String publicId, String systemId)
-            throws SAXException, IOException {
-        // Throwing an exception stops validation.
-        throw new IOException(String.format(
-                "attempt to resolve \"%s\" \"%s\"", publicId, systemId));
-    }
-}
-

Example 9.4. Helper class to prevent schema resolution in OpenJDK
-class NoResourceResolver implements LSResourceResolver {
-    @Override
-    public LSInput resolveResource(String type, String namespaceURI,
-            String publicId, String systemId, String baseURI) {
-        // Throwing an exception stops validation.
-        throw new RuntimeException(String.format(
-                "resolution attempt: type=%s namespace=%s " +
-                "publicId=%s systemId=%s baseURI=%s",
-                type, namespaceURI, publicId, systemId, baseURI));
-    }
-}
-

- Example 9.5, “Java imports for OpenJDK XML parsing” shows the imports used by the examples. -
Example 9.5. Java imports for OpenJDK XML parsing
-import javax.xml.XMLConstants;
-import javax.xml.parsers.DocumentBuilder;
-import javax.xml.parsers.DocumentBuilderFactory;
-import javax.xml.parsers.ParserConfigurationException;
-import javax.xml.parsers.SAXParser;
-import javax.xml.parsers.SAXParserFactory;
-import javax.xml.transform.dom.DOMSource;
-import javax.xml.transform.sax.SAXSource;
-import javax.xml.validation.Schema;
-import javax.xml.validation.SchemaFactory;
-import javax.xml.validation.Validator;
-
-import org.w3c.dom.Document;
-import org.w3c.dom.ls.LSInput;
-import org.w3c.dom.ls.LSResourceResolver;
-import org.xml.sax.EntityResolver;
-import org.xml.sax.ErrorHandler;
-import org.xml.sax.InputSource;
-import org.xml.sax.SAXException;
-import org.xml.sax.SAXParseException;
-import org.xml.sax.XMLReader;
-

9.4.6.1. DOM-based XML parsing and DTD validation in OpenJDK

- This approach produces a org.w3c.dom.Document object from an input stream. Example 9.6, “DOM-based XML parsing in OpenJDK” use the data from the java.io.InputStream instance in the inputStream variable. -
Example 9.6. DOM-based XML parsing in OpenJDK
-DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
-// Impose restrictions on the complexity of the DTD.
-factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
-
-// Turn on validation.
-// This step can be omitted if validation is not desired.
-factory.setValidating(true);
-
-// Parse the document.
-DocumentBuilder builder = factory.newDocumentBuilder();
-builder.setEntityResolver(new NoEntityResolver());
-builder.setErrorHandler(new Errors());
-Document document = builder.parse(inputStream);
-

- External entity references are prohibited using the NoEntityResolver class in Example 9.3, “Helper class to prevent DTD external entity resolution in OpenJDK”. Because external DTD references are prohibited, DTD validation (if enabled) will only happen against the internal DTD subset embedded in the XML document. -
- To validate the document against an external DTD, use a javax.xml.transform.Transformer class to add the DTD reference to the document, and an entity resolver which whitelists this external reference. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Validation.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Validation.html deleted file mode 100644 index 06fae75..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-Validation.html +++ /dev/null @@ -1,6 +0,0 @@ - -9.4.4. Algorithmic complexity of XML validation

Product SiteDocumentation Site

9.4.4. Algorithmic complexity of XML validation

- DTD-based XML validation uses regular expressions for content models. The XML specification requires that content models are deterministic, which means that efficient validation is possible. However, some implementations do not enforce determinism, and require exponential (or just polynomial) amount of space or time for validating some DTD/document combinations. -
- XML schemas and RELAX NG (via the xsd: prefix) directly support textual regular expressions which are not required to be deterministic. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-XInclude.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-XInclude.html deleted file mode 100644 index c4ed55e..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML-XInclude.html +++ /dev/null @@ -1,6 +0,0 @@ - -9.4.3. XInclude processing

Product SiteDocumentation Site

9.4.3. XInclude processing

- XInclude processing can reference file and network resources and include them into the document, much like external entity references. When parsing untrusted XML documents, XInclude processing should be truned off. -
- XInclude processing is also fairly complex and may pull in support for the XPointer and XPath specifications, considerably increasing the amount of code required for XML processing. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML.html b/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML.html deleted file mode 100644 index 8833c89..0000000 --- a/defensive-coding/tmp/en-US/html/sect-Defensive_Coding-Tasks-Serialization-XML.html +++ /dev/null @@ -1,30 +0,0 @@ - -9.4. XML serialization

Product SiteDocumentation Site

9.4. XML serialization

- -

9.4.1. External references

- XML documents can contain external references. They can occur in various places. -
  • - In the DTD declaration in the header of an XML document: - 
    -<!DOCTYPE html PUBLIC
-  "-//W3C//DTD XHTML 1.0 Transitional//EN"
-  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
-
  • - In a namespace declaration: - 
    -<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
-
  • - In an entity defintion: - 
    -<!ENTITY sys SYSTEM "http://www.example.com/ent.xml">
-<!ENTITY pub PUBLIC "-//Example//Public Entity//EN"
-  "http://www.example.com/pub-ent.xml">
-
  • - In a notation: - 
    -<!NOTATION not SYSTEM "../not.xml">
-
- Originally, these external references were intended as unique identifiers, but by many XML implementations, they are used for locating the data for the referenced element. This causes unwanted network traffic, and may disclose file system contents or otherwise unreachable network resources, so this functionality should be disabled. -
- Depending on the XML library, external referenced might be processed not just when parsing XML, but also when generating it. -
\ No newline at end of file diff --git a/defensive-coding/tmp/en-US/pdf/Defensive_Coding-1-Defensive_Coding-en-US.pdf b/defensive-coding/tmp/en-US/pdf/Defensive_Coding-1-Defensive_Coding-en-US.pdf deleted file mode 100644 index ee0d315..0000000 Binary files a/defensive-coding/tmp/en-US/pdf/Defensive_Coding-1-Defensive_Coding-en-US.pdf and /dev/null differ diff --git a/defensive-coding/tmp/en-US/pdf/file.eng.rdu.redhat.com b/defensive-coding/tmp/en-US/pdf/file.eng.rdu.redhat.com deleted file mode 100644 index ee0d315..0000000 Binary files a/defensive-coding/tmp/en-US/pdf/file.eng.rdu.redhat.com and /dev/null differ diff --git a/defensive-coding/tmp/en-US/pdf/file.rdu.redhat.com b/defensive-coding/tmp/en-US/pdf/file.rdu.redhat.com deleted file mode 100644 index ee0d315..0000000 Binary files a/defensive-coding/tmp/en-US/pdf/file.rdu.redhat.com and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Author_Group.xml b/defensive-coding/tmp/en-US/xml/Author_Group.xml deleted file mode 100644 index 5ab8312..0000000 --- a/defensive-coding/tmp/en-US/xml/Author_Group.xml +++ /dev/null @@ -1,19 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - Florian - Weimer - - Red Hat - Product Security Team - - - fweimer@redhat.com - - - - diff --git a/defensive-coding/tmp/en-US/xml/Book_Info.xml b/defensive-coding/tmp/en-US/xml/Book_Info.xml deleted file mode 100644 index 94391ed..0000000 --- a/defensive-coding/tmp/en-US/xml/Book_Info.xml +++ /dev/null @@ -1,32 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Defensive Coding - A Guide to Improving Software Security - 1.0 - 1.0 - - - - - - This document provides guidelines for improving software security through secure coding. It covers common programming languages and libraries, and focuses on concrete recommendations. - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/C/Allocators.xml b/defensive-coding/tmp/en-US/xml/C/Allocators.xml deleted file mode 100644 index 7aa5712..0000000 --- a/defensive-coding/tmp/en-US/xml/C/Allocators.xml +++ /dev/null @@ -1,123 +0,0 @@ - - -%BOOK_ENTITIES; -]> -
- Memory allocators -
- <function>malloc</function> and related functions - - The C library interfaces for memory allocation are provided by malloc, free and realloc, and the calloc function. In addition to these generic functions, there are derived functions such as strdup which perform allocation using malloc internally, but do not return untyped heap memory (which could be used for any object). - - - The C compiler knows about these functions and can use their expected behavior for optimizations. For instance, the compiler assumes that an existing pointer (or a pointer derived from an existing pointer by arithmetic) will not point into the memory area returned by malloc. - - - If the allocation fails, realloc does not free the old pointer. Therefore, the idiom ptr = realloc(ptr, size); is wrong because the memory pointed to by ptr leaks in case of an error. - -
- Use-after-free errors - - After free, the pointer is invalid. Further pointer dereferences are not allowed (and are usually detected by valgrind). Less obvious is that any use of the old pointer value is not allowed, either. In particular, comparisons with any other pointer (or the null pointer) are undefined according to the C standard. - - - The same rules apply to realloc if the memory area cannot be enlarged in-place. For instance, the compiler may assume that a comparison between the old and new pointer will always return false, so it is impossible to detect movement this way. - - -
- -
- Handling memory allocation errors - - Recovering from out-of-memory errors is often difficult or even impossible. In these cases, malloc and other allocation functions return a null pointer. Dereferencing this pointer lead to a crash. Such dereferences can even be exploitable for code execution if the dereference is combined with an array subscript. - - - In general, if you cannot check all allocation calls and handle failure, you should abort the program on allocation failure, and not rely on the null pointer dereference to terminate the process. See for related memory allocation concerns. - - -
- - -
- -
- <function>alloca</function> and other forms of stack-based allocation - - Allocation on the stack is risky because stack overflow checking is implicit. There is a guard page at the end of the memory area reserved for the stack. If the program attempts to read from or write to this guard page, a SIGSEGV signal is generated and the program typically terminates. - - - This is sufficient for detecting typical stack overflow situations such as unbounded recursion, but it fails when the stack grows in increments larger than the size of the guard page. In this case, it is possible that the stack pointer ends up pointing into a memory area which has been allocated for a different purposes. Such misbehavior can be exploitable. - - - A common source for large stack growth are calls to alloca and related functions such as strdupa. These functions should be avoided because of the lack of error checking. (They can be used safely if the allocated size is less than the page size (typically, 4096 bytes), but this case is relatively rare.) Additionally, relying on alloca makes it more difficult to reorgnize the code because it is not allowed to use the pointer after the function calling alloca has returned, even if this function has been inlined into its caller. - - - Similar concerns apply to variable-length arrays (VLAs), a feature of the C99 standard which started as a GNU extension. For large objects exceeding the page size, there is no error checking, either. - - - In both cases, negative or very large sizes can trigger a stack-pointer wraparound, and the stack pointer and end up pointing into caller stack frames, which is fatal and can be exploitable. - - - If you want to use alloca or VLAs for performance reasons, consider using a small on-stack array (less than the page size, large enough to fulfill most requests). If the requested size is small enough, use the on-stack array. Otherwise, call malloc. When exiting the function, check if malloc had been called, and free the buffer as needed. - - -
- -
- Array allocation - - When allocating arrays, it is important to check for overflows. The calloc function performs such checks. - - - If malloc or realloc is used, the size check must be written manually. For instance, to allocate an array of n elements of type T, check that the requested size is not greater than n / sizeof(T). - - -
- -
- Custom memory allocators - - Custom memory allocates come in two forms: replacements for malloc, and completely different interfaces for memory management. Both approaches can reduce the effectiveness of valgrind and similar tools, and the heap corruption detection provided by GNU libc, so they should be avoided. - - - Memory allocators are difficult to write and contain many performance and security pitfalls. - - - - - When computing array sizes or rounding up allocation requests (to the next allocation granularity, or for alignment purposes), checks for arithmetic overflow are required. - - - - - - Size computations for array allocations need overflow checking. See . - - - - - - It can be difficult to beat well-tuned general-purpose allocators. In micro-benchmarks, pool allocators can show huge wins, and size-specific pools can reduce internal fragmentation. But often, utilization of individual pools is poor, and - - - - - - -
- -
- Conservative garbage collection - - Garbage collection can be an alternative to explicit memory management using malloc and free. The Boehm-Dehmers-Weiser allocator can be used from C programs, with minimal type annotations. Performance is competitive with malloc on 64-bit architectures, especially for multi-threaded programs. The stop-the-world pauses may be problematic for some real-time applications, though. - - - However, using a conservative garbage collector may reduce opertunities for code reduce because once one library in a program uses garbage collection, the whole process memory needs to be subject to it, so that no pointers are missed. The Boehm-Dehmers-Weiser collector also reserves certain signals for internal use, so it is not fully transparent to the rest of the program. - - -
- -
- - diff --git a/defensive-coding/tmp/en-US/xml/C/C.xml b/defensive-coding/tmp/en-US/xml/C/C.xml deleted file mode 100644 index 8021dfb..0000000 --- a/defensive-coding/tmp/en-US/xml/C/C.xml +++ /dev/null @@ -1,12 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - The C Programming Language - - - - - diff --git a/defensive-coding/tmp/en-US/xml/C/Language.xml b/defensive-coding/tmp/en-US/xml/C/Language.xml deleted file mode 100644 index 98a4a96..0000000 --- a/defensive-coding/tmp/en-US/xml/C/Language.xml +++ /dev/null @@ -1,114 +0,0 @@ - - -%BOOK_ENTITIES; -]> -
- The core language - - C provides no memory safety. Most recommendations in this section deal with this aspect of the language. - -
- Undefined behavior - - Some C constructs are defined to be undefined by the C standard. This does not only mean that the standard does not describe what happens when the construct is executed. It also allows optimizing compilers such as GCC to assume that this particular construct is never reached. In some cases, this has caused GCC to optimize security checks away. (This is not a flaw in GCC or the C language. But C certainly has some areas which are more difficult to use than others.) - - - Common sources of undefined behavior are: - - - - - out-of-bounds array accesses - - - - - null pointer dereferences - - - - - overflow in signed integer arithmetic - - - - - -
- -
- Recommendations for pointers and array handling - - Always keep track of the size of the array you are working with. Often, code is more obviously correct when you keep a pointer past the last element of the array, and calculate the number of remaining elements by substracting the current position from that pointer. The alternative, updating a separate variable every time when the position is advanced, is usually less obviously correct. - - - shows how to extract Pascal-style strings from a character buffer. The two pointers kept for length checks are inend and outend. inp and outp are the respective positions. The number of input bytes is checked using the expression len > (size_t)(inend - inp). The cast silences a compiler warning; inend is always larger than inp. - - - Array processing in C - - - - - It is important that the length checks always have the form len > (size_t)(inend - inp), where len is a variable of type size_t which denotes the total number of bytes which are about to be read or written next. In general, it is not safe to fold multiple such checks into one, as in len1 + len2 > (size_t)(inend - inp), because the expression on the left can overflow or wrap around (see ), and it no longer reflects the number of bytes to be processed. - - -
- -
- Recommendations for integer arithmetic - - Overflow in signed integer arithmetic is undefined. This means that it is not possible to check for overflow after it happened, see . - - - Incorrect overflow detection in C - - - - - The following approaches can be used to check for overflow, without actually causing it. - - - - - Use a wider type to perform the calculation, check that the result is within bounds, and convert the result to the original type. All intermediate results must be checked in this way. - - - - - - Perform the calculation in the corresponding unsigned type and use bit fiddling to detect the overflow. - - - - - - Compute bounds for acceptable input values which are known to avoid overflow, and reject other values. This is the preferred way for overflow checking on multiplications, see . - - - - - - - Overflow checking for unsigned multiplication - - - - - Basic arithmetic operations a commutative, so for bounds checks, there are two different but mathematically equivalent expressions. Sometimes, one of the expressions results in better code because parts of it can be reduced to a constant. This applies to overflow checks for multiplication a * b involving a constant a, where the expression is reduced to b > C for some constant C determined at compile time. The other expression, b && a > ((unsigned)-1) / b, is more difficult to optimize at compile time. - - - When a value is converted to a signed integer, GCC always chooses the result based on 2's complement arithmetic. This GCC extension (which is also implemented by other compilers) helps a lot when implementing overflow checks. - - - Legacy code should be compiled with the GCC option. As a result, GCC will provide 2's complement semantics for integer arithmetic, including defined behavior on integer overflow. - - -
- -
- - diff --git a/defensive-coding/tmp/en-US/xml/C/Libc.xml b/defensive-coding/tmp/en-US/xml/C/Libc.xml deleted file mode 100644 index dbaa331..0000000 --- a/defensive-coding/tmp/en-US/xml/C/Libc.xml +++ /dev/null @@ -1,200 +0,0 @@ - - -%BOOK_ENTITIES; -]> -
- The C standard library - - Parts of the C standard library (and the UNIX and GNU extensions) are difficult to use, so you shoud avoid them. - - - Please check the applicable documentation before using the recommended replacements. Many of these functions allocate buffers using malloc which your code must deallocate explicitly using free. - -
- Absolutely banned interfaces - - The functions listed below must not be used because they are almost always unsafe. Use the indicated replacements instead. - - - - - gets ⟶ fgets - - - - - getwd ⟶ getcwd or get_current_dir_name - - - - - readdir_r ⟶ readdir - - - - - - realpath (with a non-NULL second parameter) ⟶ realpath with NULL as the second parameter, or canonicalize_file_name - - - - - - - The constants listed below must not be used, either. Instead, code must allocate memory dynamically and use interfaces with length checking. - - - - - NAME_MAX (limit not actually enforced by the kernel) - - - - - - PATH_MAX (limit not actually enforced by the kernel) - - - - - - _PC_NAME_MAX (This limit, returned by the pathconf function, is not enforced by the kernel.) - - - - - - _PC_PATH_MAX (This limit, returned by the pathconf function, is not enforced by the kernel.) - - - - - - - The following structure members must not be used. - - - - - f_namemax in struct statvfs (limit not actually enforced by the kernel, see _PC_NAME_MAX above) - - - - - - -
- -
- Functions to avoid - - The following string manipulation functions can be used securely in principle, but their use should be avoided because they are difficult to use correctly. Calls to these functions can be replaced with asprintf or vasprintf. (For non-GNU targets, these functions are available from Gnulib.) In some cases, the snprintf function might be a suitable replacement, see . - - - - - sprintf - - - - - strcat - - - - - strcpy - - - - - vsprintf - - - - - - Use the indicated replacements for the functions below. - - - - - alloca ⟶ malloc and free (see ) - - - - - - putenv ⟶ explicit envp argument in process creation (see ) - - - - - - setenv ⟶ explicit envp argument in process creation (see ) - - - - - - strdupa ⟶ strdup and free (see ) - - - - - - strndupa ⟶ strndup and free (see ) - - - - - - system ⟶ posix_spawn or fork/execve/ (see ) - - - - - - unsetenv ⟶ explicit envp argument in process creation (see ) - - - - - - -
- -
- String Functions With Explicit Length Arguments - - The snprintf function provides a way to construct a string in a statically-sized buffer. (If the buffer size is dynamic, use asprintf instead.) - - - - The second argument to the snprintf should always be the size of the buffer in the first argument (which should be a character array). Complex pointer and length arithmetic can introduce errors and nullify the security benefits of snprintf. If you need to construct a string iteratively, by repeatedly appending fragments, consider constructing the string on the heap, increasing the buffer with realloc as needed. (snprintf does not support overlapping the result buffer with argument strings.) - - - If you use vsnprintf (or snprintf) with a format string which is not a constant, but a function argument, it is important to annotate the function with a format function attribute, so that GCC can warn about misuse of your function (see ). - - - The <literal>format</literal> function attribute - - - - - There are other functions which operator on NUL-terminated strings and take a length argument which affects the number of bytes written to the destination: strncpy, strncat, and stpncpy. These functions do not ensure that the result string is NUL-terminated. For strncpy, NUL termination can be added this way: - - - - Some systems support strlcpy and strlcat functions which behave this way, but these functions are not part of GNU libc. Using snprintf with a suitable format string is a simple (albeit slightly slower) replacement. - - -
- -
- - diff --git a/defensive-coding/tmp/en-US/xml/C/schemas.xml b/defensive-coding/tmp/en-US/xml/C/schemas.xml deleted file mode 100644 index 31581c3..0000000 --- a/defensive-coding/tmp/en-US/xml/C/schemas.xml +++ /dev/null @@ -1,6 +0,0 @@ - - -%BOOK_ENTITIES; -]> - diff --git a/defensive-coding/tmp/en-US/xml/C/snippets/Arithmetic-add.xml b/defensive-coding/tmp/en-US/xml/C/snippets/Arithmetic-add.xml deleted file mode 100644 index b1b417c..0000000 --- a/defensive-coding/tmp/en-US/xml/C/snippets/Arithmetic-add.xml +++ /dev/null @@ -1,24 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -void report_overflow(void); - -int -add(int a, int b) -{ - int result = a + b; - if (a < 0 || b < 0) { - return -1; - } - // The compiler can optimize away the following if statement. - if (result < 0) { - report_overflow(); - } - return result; -} - - diff --git a/defensive-coding/tmp/en-US/xml/C/snippets/Arithmetic-mult.xml b/defensive-coding/tmp/en-US/xml/C/snippets/Arithmetic-mult.xml deleted file mode 100644 index 945f1b3..0000000 --- a/defensive-coding/tmp/en-US/xml/C/snippets/Arithmetic-mult.xml +++ /dev/null @@ -1,17 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -unsigned -mul(unsigned a, unsigned b) -{ - if (b && a > ((unsigned)-1) / b) { - report_overflow(); - } - return a * b; -} - - diff --git a/defensive-coding/tmp/en-US/xml/C/snippets/Pointers-remaining.xml b/defensive-coding/tmp/en-US/xml/C/snippets/Pointers-remaining.xml deleted file mode 100644 index cb781d0..0000000 --- a/defensive-coding/tmp/en-US/xml/C/snippets/Pointers-remaining.xml +++ /dev/null @@ -1,52 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -ssize_t -extract_strings(const char *in, size_t inlen, char **out, size_t outlen) -{ - const char *inp = in; - const char *inend = in + inlen; - char **outp = out; - char **outend = out + outlen; - - while (inp != inend) { - size_t len; - char *s; - if (outp == outend) { - errno = ENOSPC; - goto err; - } - len = (unsigned char)*inp; - ++inp; - if (len > (size_t)(inend - inp)) { - errno = EINVAL; - goto err; - } - s = malloc(len + 1); - if (s == NULL) { - goto err; - } - memcpy(s, inp, len); - inp += len; - s[len] = '\0'; - *outp = s; - ++outp; - } - return outp - out; -err: - { - int errno_old = errno; - while (out != outp) { - free(*out); - ++out; - } - errno = errno_old; - } - return -1; -} - - diff --git a/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-format.xml b/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-format.xml deleted file mode 100644 index ebc531e..0000000 --- a/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-format.xml +++ /dev/null @@ -1,21 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -void log_format(const char *format, ...) __attribute__((format(printf, 1, 2))); - -void -log_format(const char *format, ...) -{ - char buf[1000]; - va_list ap; - va_start(ap, format); - vsnprintf(buf, sizeof(buf), format, ap); - va_end(ap); - log_string(buf); -} - - diff --git a/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-snprintf.xml b/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-snprintf.xml deleted file mode 100644 index ceec25c..0000000 --- a/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-snprintf.xml +++ /dev/null @@ -1,11 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -char fraction[30]; -snprintf(fraction, sizeof(fraction), "%d/%d", numerator, denominator); - - diff --git a/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-strncpy.xml b/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-strncpy.xml deleted file mode 100644 index 89ef63d..0000000 --- a/defensive-coding/tmp/en-US/xml/C/snippets/String-Functions-strncpy.xml +++ /dev/null @@ -1,12 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -char buf[10]; -strncpy(buf, data, sizeof(buf)); -buf[sizeof(buf) - 1] = '\0'; - - diff --git a/defensive-coding/tmp/en-US/xml/CXX/CXX.xml b/defensive-coding/tmp/en-US/xml/CXX/CXX.xml deleted file mode 100644 index 8cf2f42..0000000 --- a/defensive-coding/tmp/en-US/xml/CXX/CXX.xml +++ /dev/null @@ -1,11 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - The C++ Programming Language - - - - diff --git a/defensive-coding/tmp/en-US/xml/CXX/Language.xml b/defensive-coding/tmp/en-US/xml/CXX/Language.xml deleted file mode 100644 index d8d7c18..0000000 --- a/defensive-coding/tmp/en-US/xml/CXX/Language.xml +++ /dev/null @@ -1,132 +0,0 @@ - - -%BOOK_ENTITIES; -]> -
- The core language - - C++ includes a large subset of the C language. As far as the C subset is used, the recommendations in apply. - -
- Array allocation with <literal>operator new[]</literal> - - For very large values of n, an expression like new T[n] can return a pointer to a heap region which is too small. In other words, not all array elements are actually backed with heap memory reserved to the array. Current GCC versions generate code that performs a computation of the form sizeof(T) * size_t(n) + cookie_size, where cookie_size is currently at most 8. This computation can overflow, and GCC-generated code does not detect this. - - - The std::vector template can be used instead an explicit array allocation. (The GCC implementation detects overflow internally.) - - - If there is no alternative to operator new[], code which allocates arrays with a variable length must check for overflow manually. For the new T[n] example, the size check could be n || (n > 0 && n > (size_t(-1) - 8) / sizeof(T)). (See .) If there are additional dimensions (which must be constants according to the C++ standard), these should be included as factors in the divisor. - - - These countermeasures prevent out-of-bounds writes and potential code execution. Very large memory allocations can still lead to a denial of service. contains suggestions for mitigating this problem when processing untrusted data. - - - See for array allocation advice for C-style memory allocation. - - -
- -
- Overloading - - Do not overload functions with versions that have different security characteristics. For instance, do not implement a function strcat which works on std::string arguments. Similarly, do not name methods after such functions. - - -
- -
- ABI compatibility and preparing for security updates - - A stable binary interface (ABI) is vastly preferred for security updates. Without a stable ABI, all reverse dependencies need recompiling, which can be a lot of work and could even be impossible in some cases. Ideally, a security update only updates a single dynamic shared object, and is picked up automatically after restarting affected processes. - - - Outside of extremely performance-critical code, you should ensure that a wide range of changes is possible without breaking ABI. Some very basic guidelines are: - - - - - Avoid inline functions. - - - - - - Use the pointer-to-implementation idiom. - - - - - - Try to avoid templates. Use them if the increased type safety provides a benefit to the programmer. - - - - - - Move security-critical code out of templated code, so that it can be patched in a central place if necessary. - - - - - - - The KDE project publishes a document with more extensive guidelines on ABI-preserving changes to C++ code, Policies/Binary Compatibility Issues With C++ (d-pointer refers to the pointer-to-implementation idiom). - - -
- -
- C++0X and C++11 support - - GCC offers different language compatibility modes: - - - - - for the original 1998 C++ standard - - - - - - for the 1998 standard with the changes from the TR1 technical report - - - - - - for the 2011 C++ standard. This option should not be used. - - - - - - for several different versions of C++11 support in development, depending on the GCC version. This option should not be used. - - - - - - - For each of these flags, there are variants which also enable GNU extensions (mostly language features also found in C99 or C11): , , . Again, should not be used. - - - If you enable C++11 support, the ABI of the standard C++ library libstdc++ will change in subtle ways. Currently, no C++ libraries are compiled in C++11 mode, so if you compile your code in C++11 mode, it will be incompatible with the rest of the system. Unfortunately, this is also the case if you do not use any C++11 features. Currently, there is no safe way to enable C++11 mode (except for freestanding applications). - - - The meaning of C++0X mode changed from GCC release to GCC release. Earlier versions were still ABI-compatible with C++98 mode, but in the most recent versions, switching to C++0X mode activates C++11 support, with its compatibility problems. - - - Some C++11 features (or approximations thereof) are available with TR1 support, that is, with or and in the <tr1/*> header files. This includes std::tr1::shared_ptr (from <tr1/memory>) and std::tr1::function (from <tr1/functional>). For other C++11 features, the Boost C++ library contains replacements. - - -
- -
- - diff --git a/defensive-coding/tmp/en-US/xml/CXX/Std.xml b/defensive-coding/tmp/en-US/xml/CXX/Std.xml deleted file mode 100644 index 7fa43d7..0000000 --- a/defensive-coding/tmp/en-US/xml/CXX/Std.xml +++ /dev/null @@ -1,24 +0,0 @@ - - -%BOOK_ENTITIES; -]> -
- The C++ standard library - - The C++ standard library includes most of its C counterpart by reference, see . - -
- Containers and <literal>operator[]</literal> - - Many containers similar to std::vector provide both operator[](size_type) and a member function at(size_type). This applies to std::vector itself, std::array, std::string and other instances of std::basic_string. - - - operator[](size_type) is not required by the standard to perform bounds checking (and the implementation in GCC does not). In contrast, at(size_type) must perform such a check. Therefore, in code which is not performance-critical, you should prefer at(size_type) over operator[](size_type), even though it is slightly more verbose. - - -
- -
- - diff --git a/defensive-coding/tmp/en-US/xml/CXX/schemas.xml b/defensive-coding/tmp/en-US/xml/CXX/schemas.xml deleted file mode 100644 index 31581c3..0000000 --- a/defensive-coding/tmp/en-US/xml/CXX/schemas.xml +++ /dev/null @@ -1,6 +0,0 @@ - - -%BOOK_ENTITIES; -]> - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/Conventions.xml b/defensive-coding/tmp/en-US/xml/Common_Content/Conventions.xml deleted file mode 100644 index e9a14f2..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/Conventions.xml +++ /dev/null @@ -1,178 +0,0 @@ - - -%BOOK_ENTITIES; -]> -
- Document Conventions - - This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information. - - - In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default. - -
- Typographic Conventions - - Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows. - - - Mono-spaced Bold - - - Used to highlight system input, including shell commands, file names and paths. Also used to highlight keycaps and key combinations. For example: - -
- - To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command. - - -
- - The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and all distinguishable thanks to context. - - - Key combinations can be distinguished from keycaps by the hyphen connecting each part of a key combination. For example: - -
- - Press Enter to execute the command. - - - Press CtrlAltF2 to switch to the first virtual terminal. Press CtrlAltF1 to return to your X-Windows session. - - -
- - The first paragraph highlights the particular keycap to press. The second highlights two key combinations (each a set of three keycaps with each set pressed simultaneously). - - - If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example: - -
- - File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions. - - -
- - Proportional Bold - - - This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example: - -
- - Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand). - - - To insert a special character into a gedit file, choose ApplicationsAccessoriesCharacter Map from the main menu bar. Next, choose SearchFind… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose EditPaste from the gedit menu bar. - - -
- - The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context. - - - Mono-spaced Bold Italic or Proportional Bold Italic - - - Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example: - -
- - To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com. - - - The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home. - - - To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release. - - -
- - Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system. - - - Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example: - -
- - Publican is a DocBook publishing system. - - -
- -
- -
- Pull-quote Conventions - - Terminal output and source code listings are set off visually from the surrounding text. - - - Output sent to a terminal is set in mono-spaced roman and presented thus: - - -books Desktop documentation drafts mss photos stuff svn -books_tests Desktop1 downloads images notes scripts svgs - - Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows: - - -package org.jboss.book.jca.ex1; - -import javax.naming.InitialContext; - -public class ExClient -{ - public static void main(String args[]) - throws Exception - { - InitialContext iniCtx = new InitialContext(); - Object ref = iniCtx.lookup("EchoBean"); - EchoHome home = (EchoHome) ref; - Echo echo = home.create(); - - System.out.println("Created Echo"); - - System.out.println("Echo.echo('Hello') = " + echo.echo("Hello")); - } -} - -
- -
- Notes and Warnings - - Finally, we use three visual styles to draw attention to information that might otherwise be overlooked. - - - Note - - Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier. - - - - - Important - - Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration. - - - - - Warning - - Warnings should not be ignored. Ignoring warnings will most likely cause data loss. - - - - -
- - -
- - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/Feedback.xml b/defensive-coding/tmp/en-US/xml/Common_Content/Feedback.xml deleted file mode 100644 index c8d09ad..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/Feedback.xml +++ /dev/null @@ -1,24 +0,0 @@ - - -%BOOK_ENTITIES; -]> -
- We Need Feedback! - - feedback - contact information for this manual - - - - If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/bugzilla/ against the product &PRODUCT;. - - - When submitting a bug report, be sure to mention the manual's identifier: &BOOKID; - - - If you have a suggestion for improving the documentation, try to be as specific as possible when describing it. If you have found an error, please include the section number and some of the surrounding text so we can find it easily. - -
- - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/Legal_Notice.xml b/defensive-coding/tmp/en-US/xml/Common_Content/Legal_Notice.xml deleted file mode 100644 index 0ef1087..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/Legal_Notice.xml +++ /dev/null @@ -1,38 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - Copyright &YEAR; &HOLDER;. - - - The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at . The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. - - - Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. - - - Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. - - - For guidelines on the permitted uses of the Fedora trademarks, refer to . - - - Linux is the registered trademark of Linus Torvalds in the United States and other countries. - - - Java is a registered trademark of Oracle and/or its affiliates. - - - XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. - - - MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. - - - All other trademarks are the property of their respective owners. - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/css/common.css b/defensive-coding/tmp/en-US/xml/Common_Content/css/common.css deleted file mode 100644 index d7dc3f2..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/css/common.css +++ /dev/null @@ -1,1528 +0,0 @@ -* { - widows: 2 !important; - orphans: 2 !important; -} - -body, h1, h2, h3, h4, h5, h6, pre, li, div { - line-height: 1.29em; -} - -body { - background-color: white; - margin:0 auto; - font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif; - font-size:12px; - max-width:55em; - color:black; -} - -body.toc_embeded { - /*for web hosting system only*/ - margin-left: 300px; -} - -object.toc, iframe.toc { - /*for web hosting system only*/ - border-style:none; - position:fixed; - width:290px; - height:99.99%; - top:0; - left:0; - z-index: 100; - border-style:none; - border-right:1px solid #999; -} - -/* Hide web menu */ - -body.notoc { - margin-left: 3em; -} - -iframe.notoc { - border-style:none; - border: none; - padding: 0em; - position:fixed; - width: 21px; - height: 29px; - top: 0px; - left:0; - overflow: hidden; - margin: 0em; - margin-left: -3px; -} -/* End hide web menu */ - -/* desktop styles */ -body.desktop { - margin-left: 26em; -} - -body.desktop .book > .toc { - display:block; - width:24em; - height:99%; - position:fixed; - overflow:auto; - top:0px; - left:0px; - padding-left:1em; - background-color:#EEEEEE; -} - -.toc { - line-height:1.35em; -} - -.toc .glossary, -.toc .chapter, .toc .appendix { - margin-top:1em; -} - -.toc .part { - margin-top:1em; - display:block; -} - -span.glossary, -span.appendix { - display:block; - margin-top:0.5em; -} - -div { - padding-top:0px; -} - -div.section { - padding-top:1em; -} - -p, div.para, div.formalpara { - padding-top:0px; - margin-top:0.3em; - padding-bottom:0px; - margin-bottom:1em; -} - -/*Links*/ -a { - outline: none; -} - -a:link { - text-decoration:none; - border-bottom: 1px dotted ; - color:#3366cc; -} - -a:visited { - text-decoration:none; - border-bottom: 1px dotted ; - color:#003366; -} - -div.longdesc-link { - float:right; - color:#999; -} - -.toc a, .qandaset a { - font-weight:normal; - border:none; -} - -.toc a:hover, .qandaset a:hover -{ - border-bottom: 1px dotted; -} - -/*headings*/ -h1, h2, h3, h4, h5, h6 { - color: #336699; - margin-top: 0em; - margin-bottom: 0em; - background-color: transparent; - page-break-inside: avoid; - page-break-after: avoid; -} - -h1 { - font-size:2.0em; -} - -.titlepage h1.title { - font-size: 3.0em; - padding-top: 1em; - text-align:left; -} - -.book > .titlepage h1.title { - text-align:center; -} - -.article > .titlepage h1.title { - text-align:center; -} - -.set .titlepage > div > div > h1.title { - text-align:center; -} - -.producttitle { - margin-top: 0em; - margin-bottom: 0em; - font-size: 3.0em; - font-weight: bold; - background: #003d6e url(../images/h1-bg.png) top left repeat-x; - color: white; - text-align: center; - padding: 0.7em; -} - -.titlepage .corpauthor { - margin-top: 1em; - text-align: center; -} - -.section h1.title { - font-size: 1.6em; - padding: 0em; - color: #336699; - text-align: left; - background: white; -} - -h2 { - font-size:1.6em; -} - - -h2.subtitle, h3.subtitle { - margin-top: 1em; - margin-bottom: 1em; - font-size: 1.4em; - text-align: center; -} - -.preface > div > div > div > h2.title { - margin-top: 1em; - font-size: 2.0em; -} - -.appendix h2 { - margin-top: 1em; - font-size: 2.0em; -} - - - -h3 { - font-size:1.3em; - padding-top:0em; - padding-bottom:0em; -} -h4 { - font-size:1.1em; - padding-top:0em; - padding-bottom:0em; -} - -h5 { - font-size:1em; -} - -h6 { - font-size:1em; -} - -h5.formalpara { - font-size:1em; - margin-top:2em; - margin-bottom:.8em; -} - -.abstract h6 { - margin-top:1em; - margin-bottom:.5em; - font-size:2em; -} - -/*element rules*/ -hr { - border-collapse: collapse; - border-style:none; - border-top: 1px dotted #ccc; - width:100%; - margin-top: 3em; -} - -/* web site rules */ -ul.languages, .languages li { - display:inline; - padding:0em; -} - -.languages li a { - padding:0em .5em; - text-decoration: none; -} - -.languages li p, .languages li div.para { - display:inline; -} - -.languages li a:link, .languages li a:visited { - color:#444; -} - -.languages li a:hover, .languages li a:focus, .languages li a:active { - color:black; -} - -ul.languages { - display:block; - background-color:#eee; - padding:.5em; -} - -/*supporting stylesheets*/ - -/*unique to the webpage only*/ -.books { - position:relative; -} - -.versions li { - width:100%; - clear:both; - display:block; -} - -a.version { - font-size:2em; - text-decoration:none; - width:100%; - display:block; - padding:1em 0em .2em 0em; - clear:both; -} - -a.version:before { - content:"Version"; - font-size:smaller; -} - -a.version:visited, a.version:link { - color:#666; -} - -a.version:focus, a.version:hover { - color:black; -} - -.books { - display:block; - position:relative; - clear:both; - width:100%; -} - -.books li { - display:block; - width:200px; - float:left; - position:relative; - clear: none ; -} - -.books .html { - width:170px; - display:block; -} - -.books .pdf { - position:absolute; - left:170px; - top:0px; - font-size:smaller; -} - -.books .pdf:link, .books .pdf:visited { - color:#555; -} - -.books .pdf:hover, .books .pdf:focus { - color:#000; -} - -.books li a { - text-decoration:none; -} - -.books li a:hover { - color:black; -} - -/*products*/ -.products li { - display: block; - width:300px; - float:left; -} - -.products li a { - width:300px; - padding:.5em 0em; -} - -.products ul { - clear:both; -} - -/*revision history*/ -.revhistory { - display:block; -} - -.revhistory table { - background-color:transparent; - border-color:#fff; - padding:0em; - margin: 0; - border-collapse:collapse; - border-style:none; -} - -.revhistory td { - text-align :left; - padding:0em; - border: none; - border-top: 1px solid #fff; - font-weight: bold; -} - -.revhistory .simplelist td { - font-weight: normal; -} - -.revhistory .simplelist { - margin-bottom: 1.5em; - margin-left: 1em; -} - -.revhistory table th { - display: none; -} - - -/*credits*/ -.authorgroup div { - clear:both; - text-align: center; -} - -h3.author { - margin: 0em; - padding: 0em; - padding-top: 1em; -} - -.authorgroup h4 { - padding: 0em; - margin: 0em; - padding-top: 1em; - margin-top: 1em; -} - -.author, -.editor, -.translator, -.othercredit, -.contrib { - display: block; -} - -.revhistory .author { - display: inline; -} - -.othercredit h3 { - padding-top: 1em; -} - - -.othercredit { - margin:0em; - padding:0em; -} - -.releaseinfo { - clear: both; -} - -.copyright { - margin-top: 1em; -} - -/* qanda sets */ -.answer { - margin-bottom:1em; - border-bottom:1px dotted #ccc; -} - -.qandaset .toc { - border-bottom:1px dotted #ccc; -} - -.question { - font-weight:bold; -} - -.answer .data, .question .data { - padding-left: 2.6em; -} - -.answer label, .question label { - float:left; - font-weight:bold; -} - -/* inline syntax highlighting */ -.perl_Alert { - color: #0000ff; -} - -.perl_BaseN { - color: #007f00; -} - -.perl_BString { - color: #5C3566; -} - -.perl_Char { - color: #ff00ff; -} - -.perl_Comment { - color: #FF00FF; -} - - -.perl_DataType { - color: #0000ff; -} - - -.perl_DecVal { - color: #00007f; -} - - -.perl_Error { - color: #ff0000; -} - - -.perl_Float { - color: #00007f; -} - - -.perl_Function { - color: #007f00; -} - - -.perl_IString { - color: #5C3566; -} - - -.perl_Keyword { - color: #002F5D; -} - - -.perl_Operator { - color: #ffa500; -} - - -.perl_Others { - color: #b03060; -} - - -.perl_RegionMarker { - color: #96b9ff; -} - - -.perl_Reserved { - color: #9b30ff; -} - - -.perl_String { - color: #5C3566; -} - - -.perl_Variable { - color: #0000ff; -} - - -.perl_Warning { - color: #0000ff; -} - -/*Lists*/ -ul { - padding-left:1.6em; - list-style-image:url(../images/dot.png); - list-style-type: circle; -} - -ul ul { - list-style-image:url(../images/dot2.png); - list-style-type: circle; -} - -ol { - list-style-image:none; - list-style-type: decimal; -} - -ol ol { - list-style-type: lower-alpha; -} - -ol.arabic { - list-style-type: decimal; -} - -ol.loweralpha { - list-style-type: lower-alpha; -} - -ol.lowerroman { - list-style-type: lower-roman; -} - -ol.upperalpha { - list-style-type: upper-alpha; -} - -ol.upperroman { - list-style-type: upper-roman; -} - -dt { - font-weight:bold; - margin-bottom:0em; - padding-bottom:0em; -} - -dd { - margin:0em; - margin-left:2em; - padding-top:0em; - padding-bottom: 1em; -} - -li { - padding-top:0px; - margin-top:0em; - padding-bottom:0px; - margin-bottom:0.4em; -} - -li p, li div.para { - padding-top:0px; - margin-top:0em; - padding-bottom:0px; - margin-bottom:0.3em; -} - -/*images*/ -img { - display:block; - margin: 2em 0; -} - -.inlinemediaobject, .inlinemediaobject img { - display:inline; - margin:0em; -} - -.figure img { - display:block; - margin:0; - page-break-inside: avoid; -} - -.figure .title { - margin:0em; - margin-bottom:2em; - padding:0px; -} - -/*document modes*/ -.confidential { - background-color:#900; - color:White; - padding:.5em .5em; - text-transform:uppercase; - text-align:center; -} - -.longdesc-link { - display:none; -} - -.longdesc { - display:none; -} - -.prompt { - padding:0em .3em; -} - -/*user interface styles*/ -.screen .replaceable { -} - -.guibutton, .guilabel { - font-family: "liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-weight: bold; - white-space: nowrap; -} - -.example { - background-color: #ffffff; - border-left: 3px solid #aaaaaa; - padding-top: 1em; - padding-bottom: 0.1em; -} - -.example h6 { - padding-left: 10px; -} - -.example-contents { - padding-left: 10px; - background-color: #ffffff; -} - -.example-contents .para { -/* padding: 10px;*/ -} - -/*terminal/console text*/ -.computeroutput, -.option { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-weight:bold; -} - -.replaceable { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-style: italic; -} - -.command, .filename, .keycap, .classname, .literal { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - font-weight:bold; -} - -/* no bold in toc */ -.toc * { - font-weight: inherit; -} - -pre { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; - display:block; - background-color: #f5f5f5; - color: #000000; - border: 1px solid #aaaaaa; - margin-bottom: 0.3em; - padding:.5em 1em; - white-space: pre-wrap; /* css-3 */ - white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */ - white-space: -pre-wrap; /* Opera 4-6 */ - white-space: -o-pre-wrap; /* Opera 7 */ - word-wrap: break-word; /* Internet Explorer 5.5+ */ - font-size: 0.9em; -} - -pre .replaceable, -pre .keycap { -} - -code { - font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace; -/* white-space: nowrap;*/ - white-space: pre-wrap; - word-wrap: break-word; - font-weight:bold; -} - -.parameter code { - display: inline; - white-space: pre-wrap; /* css-3 */ - white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */ - white-space: -pre-wrap; /* Opera 4-6 */ - white-space: -o-pre-wrap; /* Opera 7 */ - word-wrap: break-word; /* Internet Explorer 5.5+ */ -} - -/*Notifications*/ -div.warning:before { - content:url(../images/warning.png); - padding-left: 5px; -} - -div.note:before { - content:url(../images/note.png); - padding-left: 5px; -} - -div.important:before { - content:url(../images/important.png); - padding-left: 5px; -} - -div.warning, div.note, div.important { - color: black; - margin: 0em; - padding: 0em; - background: none; - background-color: white; - margin-bottom: 1em; - border-bottom: 1px solid #aaaaaa; - page-break-inside: avoid; -} - -div.warning h2, div.note h2,div.important h2 { - margin: 0em; - padding: 0em; - color: #eeeeec; - padding-top: 0px; - padding-bottom: 0px; - height: 1.4em; - line-height: 1.4em; - font-size: 1.4em; - display:inline; -} - -div.admonition_header { - clear: both; - margin: 0em; - padding: 0em; - margin-top: -3.3em; - padding-left: 58px; - line-height: 1.0em; - font-size: 1.0em; -} - -div.warning div.admonition_header { - background: url(../images/red.png) top left repeat-x; - background-color: #590000; -} - -div.note div.admonition_header { - background: url(../images/green.png) top right repeat-x; - background-color: #597800; -} - -div.important div.admonition_header { - background: url(../images/yellow.png) top right repeat-x; - background-color: #a6710f; -} - -div.warning p, div.warning div.para, -div.note p, div.note div.para, -div.important p, div.important div.para { - padding: 0em; - margin: 0em; -} - -div.admonition { - border: none; - border-left: 1px solid #aaaaaa; - border-right: 1px solid #aaaaaa; - padding:0em; - margin:0em; - padding-top: 1.5em; - padding-bottom: 1em; - padding-left: 2em; - padding-right: 1em; - background-color: #eeeeec; - -moz-border-radius: 0px; - -webkit-border-radius: 0px; - border-radius: 0px; -} - -/*Page Title*/ -#title { - display:block; - height:45px; - padding-bottom:1em; - margin:0em; -} - -#title a.left{ - display:inline; - border:none; -} - -#title a.left img{ - border:none; - float:left; - margin:0em; - margin-top:.7em; -} - -#title a.right { - padding-bottom:1em; -} - -#title a.right img { - border:none; - float:right; - margin:0em; - margin-top:.7em; -} - -/*Table*/ -div.table { - page-break-inside: avoid; -} - -table { - border:1px solid #6c614b; - width:100%; - border-collapse:collapse; -} - -table.simplelist, .calloutlist table { - border-style: none; -} - -table th { - text-align:left; - background-color:#6699cc; - padding:.3em .5em; - color:white; -} - -table td { - padding:.15em .5em; -} - -table tr.even td { - background-color:#f5f5f5; -} - -table th p:first-child, table td p:first-child, table li p:first-child, -table th div.para:first-child, table td div.para:first-child, table li div.para:first-child { - margin-top:0em; - padding-top:0em; - display:inline; -} - -th, td { - border-style:none; - vertical-align: top; - border: 1px solid #000; -} - -.simplelist th, .simplelist td { - border: none; -} - -table table td { - border-bottom:1px dotted #aaa; - background-color:white; - padding:.6em 0em; -} - -table table { - border:1px solid white; -} - -td.remarkval { - color:#444; -} - -td.fieldval { - font-weight:bold; -} - -.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost { - color:white; - font-weight:bold; - background-color:#999; - width:120px; -} - -td.remarkval { - width:230px; -} - -td.tname { - font-weight:bold; -} - -th.dbfield { - width:120px; -} - -th.dbtype { - width:70px; -} - -th.dbdefault { - width:70px; -} - -th.dbnul { - width:70px; -} - -th.dbkey { - width:70px; -} - -span.book { - margin-top:4em; - display:block; - font-size:11pt; -} - -span.book a{ - font-weight:bold; -} -span.chapter { - display:block; - margin-top:0.5em; -} - -table.simplelist td, .calloutlist table td { - border-style: none; -} - -/*Breadcrumbs*/ -#breadcrumbs ul li.first:before { - content:" "; -} - -#breadcrumbs { - color:#900; - padding:3px; - margin-bottom:25px; -} - -#breadcrumbs ul { - margin-left:0; - padding-left:0; - display:inline; - border:none; -} - -#breadcrumbs ul li { - margin-left:0; - padding-left:2px; - border:none; - list-style:none; - display:inline; -} - -#breadcrumbs ul li:before { - content:"\0020 \0020 \0020 \00BB \0020"; - color:#333; -} - -/*index*/ -.glossary h3, -.index h3 { - font-size: 2em; - color:#aaa; - margin:0em; -} - -.indexdiv { - margin-bottom:1em; -} - -.glossary dt, -.index dt { - color:#444; - padding-top:.5em; -} - -.glossary dl dl dt, -.index dl dl dt { - color:#777; - font-weight:normal; - padding-top:0em; -} - -.index dl dl dt:before { - content:"- "; - color:#ccc; -} - -/*changes*/ -.footnote { - font-size: .7em; - margin:0em; - color:#222; -} - -table .footnote { -} - -sup { - color:#999; - margin:0em; - padding:0em; - line-height: .4em; - font-size: 1em; - padding-left:0em; -} - -.footnote { - position:relative; -} - -.footnote sup { - color:#e3dcc0; - position:absolute; - left: .4em; -} - -.footnote sup a:link, -.footnote sup a:visited { - color:#92917d; - text-decoration:none; -} - -.footnote:hover sup a { - text-decoration:none; -} - -.footnote p,.footnote div.para { - padding-left:2em; -} - -.footnote a:link, -.footnote a:visited { - color:#00537c; -} - -.footnote a:hover { -} - -/**/ -div.chapter { - margin-top:3em; - page-break-inside: avoid; -} - -div.preface { - page-break-inside: avoid; -} - -div.section { - margin-top:1em; - page-break-inside: auto; -} - -div.note .replaceable, -div.important .replaceable, -div.warning .replaceable, -div.note .keycap, -div.important .keycap, -div.warning .keycap -{ -} - -ul li p:last-child, ul li div.para:last-child { - margin-bottom:0em; - padding-bottom:0em; -} - -/*document navigation*/ -.docnav a, .docnav strong { - border:none; - text-decoration:none; - font-weight:normal; -} - -.docnav { - list-style:none; - margin:0em; - padding:0em; - position:relative; - width:100%; - padding-bottom:2em; - padding-top:1em; - border-top:1px dotted #ccc; -} - -.docnav li { - list-style:none; - margin:0em; - padding:0em; - display:inline; - font-size:.8em; -} - -.docnav li:before { - content:" "; -} - -.docnav li.previous, .docnav li.next { - position:absolute; - top:1em; -} - -.docnav li.up, .docnav li.home { - margin:0em 1.5em; -} - -.docnav li.previous { - left:0px; - text-align:left; -} - -.docnav li.next { - right:0px; - text-align:right; -} - -.docnav li.previous strong, .docnav li.next strong { - height:22px; - display:block; -} - -.docnav { - margin:0 auto; - text-align:center; -} - -.docnav li.next a strong { - background: url(../images/stock-go-forward.png) top right no-repeat; - padding-top:3px; - padding-bottom:4px; - padding-right:28px; - font-size:1.2em; -} - -.docnav li.previous a strong { - background: url(../images/stock-go-back.png) top left no-repeat; - padding-top:3px; - padding-bottom:4px; - padding-left:28px; - padding-right:0.5em; - font-size:1.2em; -} - -.docnav li.home a strong { - background: url(../images/stock-home.png) top left no-repeat; - padding:5px; - padding-left:28px; - font-size:1.2em; -} - -.docnav li.up a strong { - background: url(../images/stock-go-up.png) top left no-repeat; - padding:5px; - padding-left:28px; - font-size:1.2em; -} - -.docnav a:link, .docnav a:visited { - color:#666; -} - -.docnav a:hover, .docnav a:focus, .docnav a:active { - color:black; -} - -.docnav a { - max-width: 10em; - overflow:hidden; -} - -.docnav a:link strong { - text-decoration:none; -} - -.docnav { - margin:0 auto; - text-align:center; -} - -ul.docnav { - margin-bottom: 1em; -} -/* Reports */ -.reports ul { - list-style:none; - margin:0em; - padding:0em; -} - -.reports li{ - margin:0em; - padding:0em; -} - -.reports li.odd { - background-color: #eeeeee; - margin:0em; - padding:0em; -} - -.reports dl { - display:inline; - margin:0em; - padding:0em; - float:right; - margin-right: 17em; - margin-top:-1.3em; -} - -.reports dt { - display:inline; - margin:0em; - padding:0em; -} - -.reports dd { - display:inline; - margin:0em; - padding:0em; - padding-right:.5em; -} - -.reports h2, .reports h3{ - display:inline; - padding-right:.5em; - font-size:10pt; - font-weight:normal; -} - -.reports div.progress { - display:inline; - float:right; - width:16em; - background:#c00 url(../images/shine.png) top left repeat-x; - margin:0em; - margin-top:-1.3em; - padding:0em; - border:none; -} - -/*uniform*/ -body.results, body.reports { - max-width:57em ; - padding:0em; -} - -/*Progress Bar*/ -div.progress { - display:block; - float:left; - width:16em; - background:#c00 url(../images/shine.png) top left repeat-x; - height:1em; -} - -div.progress span { - height:1em; - float:left; -} - -div.progress span.translated { - background:#6c3 url(../images/shine.png) top left repeat-x; -} - -div.progress span.fuzzy { - background:#ff9f00 url(../images/shine.png) top left repeat-x; -} - - -/*Results*/ - -.results ul { - list-style:none; - margin:0em; - padding:0em; -} - -.results li{ - margin:0em; - padding:0em; -} - -.results li.odd { - background-color: #eeeeee; - margin:0em; - padding:0em; -} - -.results dl { - display:inline; - margin:0em; - padding:0em; - float:right; - margin-right: 17em; - margin-top:-1.3em; -} - -.results dt { - display:inline; - margin:0em; - padding:0em; -} - -.results dd { - display:inline; - margin:0em; - padding:0em; - padding-right:.5em; -} - -.results h2, .results h3 { - display:inline; - padding-right:.5em; - font-size:10pt; - font-weight:normal; -} - -.results div.progress { - display:inline; - float:right; - width:16em; - background:#c00 url(../images/shine.png) top left repeat-x; - margin:0em; - margin-top:-1.3em; - padding:0em; - border:none; -} - -/* Dirty EVIL Mozilla hack for round corners */ -pre { - -moz-border-radius:11px; - -webkit-border-radius:11px; - border-radius: 11px; - page-break-inside: avoid; -} - -.example { - -moz-border-radius:0px; - -webkit-border-radius:0px; - border-radius: 0px; - page-break-inside: avoid; -} - -.package, .citetitle { - font-style: italic; -} - -.titlepage .edition { - color: #336699; - background-color: transparent; - margin-top: 1em; - margin-bottom: 1em; - font-size: 1.4em; - font-weight: bold; - text-align: center; -} - -span.remark { - background-color: #ff00ff; -} - -.draft { - background-image: url(../images/watermark-draft.png); - background-repeat: repeat-y; - background-position: center; -} - -.foreignphrase { - font-style: inherit; -} - -dt { - clear:both; -} - -dt img { - border-style: none; - max-width: 112px; -} - -dt object { - max-width: 112px; -} - -dt .inlinemediaobject, dt object { - display: inline; - float: left; - margin-bottom: 1em; - padding-right: 1em; - width: 112px; -} - -dl:after { - display: block; - clear: both; - content: ""; -} - -.toc dd { - padding-bottom: 0em; - margin-bottom: 1em; - padding-left: 1.3em; - margin-left: 0em; -} - -div.toc > dl > dt { - padding-bottom: 0em; - margin-bottom: 0em; - margin-top: 1em; -} - - -.strikethrough { - text-decoration: line-through; -} - -.underline { - text-decoration: underline; -} - -.calloutlist img, .callout { - padding: 0em; - margin: 0em; - width: 12pt; - display: inline; - vertical-align: middle; -} - -.stepalternatives { - list-style-image: none; - list-style-type: none; -} - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/css/default.css b/defensive-coding/tmp/en-US/xml/Common_Content/css/default.css deleted file mode 100644 index bf38ebb..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/css/default.css +++ /dev/null @@ -1,3 +0,0 @@ -@import url("common.css"); -@import url("overrides.css"); -@import url("lang.css"); diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/css/lang.css b/defensive-coding/tmp/en-US/xml/Common_Content/css/lang.css deleted file mode 100644 index 81c3115..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/css/lang.css +++ /dev/null @@ -1,2 +0,0 @@ -/* place holder */ - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/css/overrides.css b/defensive-coding/tmp/en-US/xml/Common_Content/css/overrides.css deleted file mode 100644 index 057be29..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/css/overrides.css +++ /dev/null @@ -1,51 +0,0 @@ -a:link { - color:#0066cc; -} - -a:hover, a:active { - color:#003366; -} - -a:visited { - color:#6699cc; -} - - -h1 { - color:#3c6eb4 -} - -.producttitle { - background: #3c6eb4 url(../images/h1-bg.png) top left repeat; -} - -.section h1.title { - color:#3c6eb4; -} - - -h2,h3,h4,h5,h6 { - color:#3c6eb4; -} - -table { - border:1px solid #3c6eb4; -} - -table th { - background-color:#3c6eb4; -} - - -table tr.even td { - background-color:#f5f5f5; -} - -.revhistory table th { - color:#3c6eb4; -} - -.titlepage .edition { - color: #3c6eb4; -} - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/css/print.css b/defensive-coding/tmp/en-US/xml/Common_Content/css/print.css deleted file mode 100644 index 773d8ae..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/css/print.css +++ /dev/null @@ -1,16 +0,0 @@ -@import url("common.css"); -@import url("overrides.css"); -@import url("lang.css"); - -#tocframe { - display: none; -} - -body.toc_embeded { - margin-left: 30px; -} - -.producttitle { - color: #336699; -} - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/1.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/1.png deleted file mode 100644 index c21d7a3..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/1.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/1.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/1.svg deleted file mode 100644 index a2b3903..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/1.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/10.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/10.png deleted file mode 100644 index 15b81da..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/10.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/10.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/10.svg deleted file mode 100644 index af015ab..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/10.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/11.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/11.png deleted file mode 100644 index 2fcc2dd..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/11.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/11.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/11.svg deleted file mode 100644 index cb82b70..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/11.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/12.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/12.png deleted file mode 100644 index edebe20..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/12.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/12.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/12.svg deleted file mode 100644 index 3b6d822..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/12.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/13.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/13.png deleted file mode 100644 index ec48cef..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/13.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/13.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/13.svg deleted file mode 100644 index 226e461..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/13.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/14.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/14.png deleted file mode 100644 index 33d5637..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/14.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/14.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/14.svg deleted file mode 100644 index 5aaa3a3..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/14.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/15.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/15.png deleted file mode 100644 index f1a4eb2..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/15.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/15.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/15.svg deleted file mode 100644 index f51dd96..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/15.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/16.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/16.png deleted file mode 100644 index d38a155..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/16.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/16.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/16.svg deleted file mode 100644 index cb7e2f5..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/16.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/17.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/17.png deleted file mode 100644 index d83e898..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/17.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/17.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/17.svg deleted file mode 100644 index 5d6f0ad..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/17.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/18.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/18.png deleted file mode 100644 index 9e39de4..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/18.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/18.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/18.svg deleted file mode 100644 index 9ea672c..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/18.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/19.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/19.png deleted file mode 100644 index 9eeedfb..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/19.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/19.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/19.svg deleted file mode 100644 index 80d1d09..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/19.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/2.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/2.png deleted file mode 100644 index ff9cc57..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/2.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/2.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/2.svg deleted file mode 100644 index 8e94260..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/2.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/20.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/20.png deleted file mode 100644 index b28b4aa..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/20.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/20.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/20.svg deleted file mode 100644 index 409ac6e..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/20.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/21.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/21.png deleted file mode 100644 index eda952c..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/21.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/21.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/21.svg deleted file mode 100644 index 7bc03af..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/21.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/22.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/22.png deleted file mode 100644 index 90b14b0..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/22.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/22.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/22.svg deleted file mode 100644 index fe086f6..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/22.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/23.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/23.png deleted file mode 100644 index 8b35a74..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/23.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/23.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/23.svg deleted file mode 100644 index f17ec29..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/23.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/24.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/24.png deleted file mode 100644 index 6041b02..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/24.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/24.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/24.svg deleted file mode 100644 index 42a5333..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/24.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/25.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/25.png deleted file mode 100644 index ecb15e6..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/25.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/25.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/25.svg deleted file mode 100644 index a8d4672..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/25.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/26.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/26.png deleted file mode 100644 index 4b2f560..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/26.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/26.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/26.svg deleted file mode 100644 index 3cf00ec..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/26.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/27.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/27.png deleted file mode 100644 index ecf058e..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/27.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/27.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/27.svg deleted file mode 100644 index c8d6440..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/27.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/28.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/28.png deleted file mode 100644 index e64efb2..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/28.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/28.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/28.svg deleted file mode 100644 index 5acce93..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/28.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/29.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/29.png deleted file mode 100644 index dbbca1b..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/29.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/29.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/29.svg deleted file mode 100644 index 507dd44..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/29.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/3.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/3.png deleted file mode 100644 index 4febe43..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/3.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/3.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/3.svg deleted file mode 100644 index 5e87e1f..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/3.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/30.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/30.png deleted file mode 100644 index f4ffb14..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/30.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/30.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/30.svg deleted file mode 100644 index 434e663..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/30.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/31.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/31.png deleted file mode 100644 index 0b29e87..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/31.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/31.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/31.svg deleted file mode 100644 index 08c3f2d..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/31.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/32.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/32.png deleted file mode 100644 index a4740a3..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/32.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/32.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/32.svg deleted file mode 100644 index aa099c3..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/32.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/33.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/33.png deleted file mode 100644 index f23ccea..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/33.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/33.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/33.svg deleted file mode 100644 index fce979c..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/33.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/34.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/34.png deleted file mode 100644 index 7e2ab31..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/34.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/34.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/34.svg deleted file mode 100644 index c67f8ec..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/34.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/35.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/35.png deleted file mode 100644 index 02118e3..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/35.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/35.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/35.svg deleted file mode 100644 index da7780a..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/35.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/36.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/36.png deleted file mode 100644 index 30f4fdf..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/36.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/36.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/36.svg deleted file mode 100644 index 348549a..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/36.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/37.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/37.png deleted file mode 100644 index 6174706..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/37.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/37.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/37.svg deleted file mode 100644 index 7bc04d9..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/37.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/38.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/38.png deleted file mode 100644 index 161661d..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/38.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/38.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/38.svg deleted file mode 100644 index ec2ad98..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/38.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/39.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/39.png deleted file mode 100644 index 2d46b24..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/39.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/39.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/39.svg deleted file mode 100644 index 664ffdd..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/39.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/4.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/4.png deleted file mode 100644 index 9b9dd88..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/4.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/4.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/4.svg deleted file mode 100644 index bc06c73..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/4.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/40.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/40.png deleted file mode 100644 index fe2a68f..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/40.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/40.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/40.svg deleted file mode 100644 index 5a94d1b..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/40.svg +++ /dev/null @@ -1,31 +0,0 @@ - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/5.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/5.png deleted file mode 100644 index f239fb6..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/5.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/5.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/5.svg deleted file mode 100644 index 82fb03d..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/5.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/6.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/6.png deleted file mode 100644 index 18866e6..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/6.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/6.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/6.svg deleted file mode 100644 index e2f62af..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/6.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/7.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/7.png deleted file mode 100644 index 52c3a18..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/7.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/7.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/7.svg deleted file mode 100644 index a43460f..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/7.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/8.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/8.png deleted file mode 100644 index 8a8cb21..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/8.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/8.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/8.svg deleted file mode 100644 index 2c82d3f..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/8.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/9.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/9.png deleted file mode 100644 index 0ae412f..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/9.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/9.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/9.svg deleted file mode 100644 index b0f04c4..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/9.svg +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/bkgrnd_greydots.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/bkgrnd_greydots.png deleted file mode 100644 index 2333a6d..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/bkgrnd_greydots.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/bullet_arrowblue.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/bullet_arrowblue.png deleted file mode 100644 index c235534..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/bullet_arrowblue.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/documentation.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/documentation.png deleted file mode 100644 index 79d0a80..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/documentation.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/dot.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/dot.png deleted file mode 100644 index 36a6859..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/dot.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/dot2.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/dot2.png deleted file mode 100644 index 40aff92..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/dot2.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/green.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/green.png deleted file mode 100644 index ebb3c24..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/green.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/h1-bg.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/h1-bg.png deleted file mode 100644 index a2aad24..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/h1-bg.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/image_left.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/image_left.png deleted file mode 100644 index e8fe7a4..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/image_left.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/image_right.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/image_right.png deleted file mode 100644 index 5b67443..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/image_right.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/important.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/important.png deleted file mode 100644 index f7594a3..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/important.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/important.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/important.svg deleted file mode 100644 index 2d33045..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/important.svg +++ /dev/null @@ -1,106 +0,0 @@ - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/logo.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/logo.png deleted file mode 100644 index 66a3104..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/logo.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/note.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/note.png deleted file mode 100644 index d6c4518..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/note.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/note.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/note.svg deleted file mode 100644 index 70e43b6..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/note.svg +++ /dev/null @@ -1,111 +0,0 @@ - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/red.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/red.png deleted file mode 100644 index d32d5e2..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/red.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/redhat-logo.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/redhat-logo.svg deleted file mode 100644 index 1001776..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/redhat-logo.svg +++ /dev/null @@ -1,94 +0,0 @@ - - - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/rhlogo.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/rhlogo.png deleted file mode 100644 index ecd4856..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/rhlogo.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/shade.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/shade.png deleted file mode 100644 index a73afdf..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/shade.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/shine.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/shine.png deleted file mode 100644 index a18f7c4..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/shine.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-back.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-back.png deleted file mode 100644 index d320f26..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-back.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-forward.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-forward.png deleted file mode 100644 index 1ee5a29..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-forward.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-up.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-up.png deleted file mode 100644 index 1cd7332..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-go-up.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-home.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-home.png deleted file mode 100644 index 122536d..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/stock-home.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/title_logo.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/title_logo.png deleted file mode 100644 index d5182b4..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/title_logo.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/title_logo.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/title_logo.svg deleted file mode 100644 index e8fd52b..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/title_logo.svg +++ /dev/null @@ -1,61 +0,0 @@ - - - - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/warning.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/warning.png deleted file mode 100644 index ce09951..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/warning.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/warning.svg b/defensive-coding/tmp/en-US/xml/Common_Content/images/warning.svg deleted file mode 100644 index 5f2612c..0000000 --- a/defensive-coding/tmp/en-US/xml/Common_Content/images/warning.svg +++ /dev/null @@ -1,89 +0,0 @@ - - - - - - - image/svg+xml - - - - - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/watermark-draft.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/watermark-draft.png deleted file mode 100644 index 0ead5af..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/watermark-draft.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Common_Content/images/yellow.png b/defensive-coding/tmp/en-US/xml/Common_Content/images/yellow.png deleted file mode 100644 index 223865d..0000000 Binary files a/defensive-coding/tmp/en-US/xml/Common_Content/images/yellow.png and /dev/null differ diff --git a/defensive-coding/tmp/en-US/xml/Defensive_Coding.ent b/defensive-coding/tmp/en-US/xml/Defensive_Coding.ent deleted file mode 100644 index 0bf84b7..0000000 --- a/defensive-coding/tmp/en-US/xml/Defensive_Coding.ent +++ /dev/null @@ -1,2 +0,0 @@ - - diff --git a/defensive-coding/tmp/en-US/xml/Defensive_Coding.fo b/defensive-coding/tmp/en-US/xml/Defensive_Coding.fo deleted file mode 100644 index d7b8779..0000000 --- a/defensive-coding/tmp/en-US/xml/Defensive_Coding.fo +++ /dev/null @@ -1,1946 +0,0 @@ - -Defensive Coding - A Guide to Improving Software SecurityDocBook XSL Stylesheets with Apache FOPDefensive CodingTable of ContentsPart I. Programming LanguagesChapter 1. The C Programming Language1.1. The core language1.1.1. Undefined behavior1.1.2. Recommendations for pointers and array handling1.1.3. Recommendations for integer arithmetic1.2. The C standard library1.2.1. Absolutely banned interfaces1.2.2. Functions to avoid1.2.3. String Functions With Explicit Length Arguments1.3. Memory allocators1.3.1. malloc and related functions1.3.1.1. Use-after-free errors1.3.1.2. Handling memory allocation errors1.3.2. alloca and other forms of stack-based allocation1.3.3. Array allocation1.3.4. Custom memory allocators1.3.5. Conservative garbage collectionChapter 2. The C++ Programming Language2.1. The core language2.1.1. Array allocation with operator new[]2.1.2. Overloading2.1.3. ABI compatibility and preparing for security updates2.1.4. C++0X and C++11 support2.2. The C++ standard library2.2.1. Containers and operator[]Chapter 3. The Python Programming Language3.1. Dangerous standard library features3.2. Run-time compilation and code generation3.3. SandboxingPart II. Specific Programming TasksChapter 4. Library Design4.1. State management4.1.1. Global state4.1.2. Handles4.2. Object orientation4.3. Callbacks4.4. Process attributesChapter 5. File Descriptor Management5.1. Closing descriptors5.1.1. Error handling during descriptor close5.1.2. Closing descriptors and race conditions5.1.3. Lingering state after close5.2. Preventing file descriptor leaks to child processes5.3. Dealing with the select limitChapter 6. File system manipulation6.1. Working with files and directories owned by other users6.2. Accessing the file system as a different user6.3. File system limits6.4. File system features6.5. Checking free spaceChapter 7. Temporary files7.1. Obtaining the location of temporary directory7.2. Named temporary files7.3. Temporary files without names7.4. Temporary directories7.5. Compensating for unsafe file creationChapter 8. Processes8.1. Safe process creation8.1.1. Obtaining the program path and the command line template8.1.2. Bypassing the shell8.1.3. Specifying the process environment8.1.4. Robust argument list processing8.1.5. Passing secrets to subprocesses8.2. Handling child process termination8.3. SUID/SGID processes8.3.1. Accessing environment variables8.4. Daemons8.5. Semantics of command line arguments8.6. fork as a primitive for parallelismChapter 9. Serialization and Deserialization9.1. Recommendations for manually written decoders9.2. Protocol design9.3. Library support for deserialization9.4. XML serialization9.4.1. External references9.4.2. Entity expansion9.4.3. XInclude processing9.4.4. Algorithmic complexity of XML validation9.4.5. Using Expat for XML parsing9.4.6. Using OpenJDK for XML parsing and validation9.4.6.1. DOM-based XML parsing and DTD validation in OpenJDK9.4.6.2. XML Schema validation in OpenJDK9.5. Protocol EncodersChapter 10. Cryptography10.1. Primitives10.2. RandomnessPart III. Implementing Security FeaturesChapter 11. Authentication and Authorization11.1. Authenticating servers11.2. Host-based authentication11.3. UNIX domain socket authentication11.4. AF_NETLINK authentication of originChapter 12. Transport Layer Security12.1. Common Pitfalls12.1.1. OpenSSL Pitfalls12.1.2. GNUTLS Pitfalls12.1.3. OpenJDK Pitfalls12.1.4. NSS Pitfalls12.2. TLS Clients12.2.1. Implementation TLS Clients With OpenSSL12.2.2. Implementation TLS Clients With GNUTLS12.2.3. Implementing TLS Clients With OpenJDK12.2.3.1. Overriding server certificate validation with OpenJDK 612.2.4. Implementing TLS Clients With NSS12.2.5. Implementing TLS Clients With PythonAppendix A. Revision HistoryDefensive Coding Defensive CodingA Guide to Improving Software Security - - - Florian Weimer Defensive CodingA Guide to Improving Software SecurityEdition 1.0AuthorFlorian Weimerfweimer@redhat.com - Copyright © 2012 Red Hat, Inc. - - The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. - - Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. - - Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. - - For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines. - - Linux® is the registered trademark of Linus Torvalds in the United States and other countries. - - Java® is a registered trademark of Oracle and/or its affiliates. - - XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. - - MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries. - - All other trademarks are the property of their respective owners. - - This document provides guidelines for improving software security through secure coding. It covers common programming languages and libraries, and focuses on concrete recommendations. - Defensive CodingI. Programming Languages   1. The C Programming Language   1.1. The core language 1.1.1. Undefined behavior 1.1.2. Recommendations for pointers and array handling 1.1.3. Recommendations for integer arithmetic 1.2. The C standard library 1.2.1. Absolutely banned interfaces 1.2.2. Functions to avoid 1.2.3. String Functions With Explicit Length Arguments 1.3. Memory allocators 1.3.1. malloc and related functions 1.3.2. alloca and other forms of stack-based allocation 1.3.3. Array allocation 1.3.4. Custom memory allocators 1.3.5. Conservative garbage collection 2. The C++ Programming Language   2.1. The core language 2.1.1. Array allocation with operator new[] 2.1.2. Overloading 2.1.3. ABI compatibility and preparing for security updates 2.1.4. C++0X and C++11 support 2.2. The C++ standard library 2.2.1. Containers and operator[] 3. The Python Programming Language   3.1. Dangerous standard library features 3.2. Run-time compilation and code generation 3.3. Sandboxing II. Specific Programming Tasks   4. Library Design   4.1. State management 4.1.1. Global state 4.1.2. Handles 4.2. Object orientation 4.3. Callbacks 4.4. Process attributes 5. File Descriptor Management   5.1. Closing descriptors 5.1.1. Error handling during descriptor close 5.1.2. Closing descriptors and race conditions 5.1.3. Lingering state after close 5.2. Preventing file descriptor leaks to child processes 5.3. Dealing with the select limit 6. File system manipulation   6.1. Working with files and directories owned by other users 6.2. Accessing the file system as a different user 6.3. File system limits 6.4. File system features 6.5. Checking free space 7. Temporary files   7.1. Obtaining the location of temporary directory 7.2. Named temporary files 7.3. Temporary files without names 7.4. Temporary directories 7.5. Compensating for unsafe file creation 8. Processes   8.1. Safe process creation 8.1.1. Obtaining the program path and the command line template 8.1.2. Bypassing the shell 8.1.3. Specifying the process environment 8.1.4. Robust argument list processing 8.1.5. Passing secrets to subprocesses 8.2. Handling child process termination 8.3. SUID/SGID processes 8.3.1. Accessing environment variables 8.4. Daemons 8.5. Semantics of command line arguments 8.6. fork as a primitive for parallelism 9. Serialization and Deserialization   9.1. Recommendations for manually written decoders 9.2. Protocol design 9.3. Library support for deserialization 9.4. XML serialization 9.4.1. External references 9.4.2. Entity expansion 9.4.3. XInclude processing 9.4.4. Algorithmic complexity of XML validation 9.4.5. Using Expat for XML parsing 9.4.6. Using OpenJDK for XML parsing and validation 9.5. Protocol Encoders 10. Cryptography   10.1. Primitives 10.2. Randomness III. Implementing Security Features   11. Authentication and Authorization   11.1. Authenticating servers 11.2. Host-based authentication 11.3. UNIX domain socket authentication 11.4. AF_NETLINK authentication of origin 12. Transport Layer Security   12.1. Common Pitfalls 12.1.1. OpenSSL Pitfalls 12.1.2. GNUTLS Pitfalls 12.1.3. OpenJDK Pitfalls 12.1.4. NSS Pitfalls 12.2. TLS Clients 12.2.1. Implementation TLS Clients With OpenSSL 12.2.2. Implementation TLS Clients With GNUTLS 12.2.3. Implementing TLS Clients With OpenJDK 12.2.4. Implementing TLS Clients With NSS 12.2.5. Implementing TLS Clients With Python A. Revision History   Part I. Programming LanguagesPart I. Programming LanguagesChapter 1.Chapter 1. The C Programming LanguageThe C Programming LanguageThe core language1.1. The core language - C provides no memory safety. Most recommendations in this section deal with this aspect of the language. - Undefined behavior1.1.1. Undefined behavior - Some C constructs are defined to be undefined by the C standard. This does not only mean that the standard does not describe what happens when the construct is executed. It also allows optimizing compilers such as GCC to assume that this particular construct is never reached. In some cases, this has caused GCC to optimize security checks away. (This is not a flaw in GCC or the C language. But C certainly has some areas which are more difficult to use than others.) - - Common sources of undefined behavior are: - • - out-of-bounds array accesses - • - null pointer dereferences - • - overflow in signed integer arithmetic - Recommendations for pointers and array handling1.1.2. Recommendations for pointers and array handling - Always keep track of the size of the array you are working with. Often, code is more obviously correct when you keep a pointer past the last element of the array, and calculate the number of remaining elements by substracting the current position from that pointer. The alternative, updating a separate variable every time when the position is advanced, is usually less obviously correct. - - Example 1.1, “Array processing in C” shows how to extract Pascal-style strings from a character buffer. The two pointers kept for length checks are inend and outend. inp and outp are the respective positions. The number of input bytes is checked using the expression len > (size_t)(inend - inp). The cast silences a compiler warning; inend is always larger than inp. - Example 1.1. Array processing in C -ssize_t -extract_strings(const char *in, size_t inlen, char **out, size_t outlen) -{ - const char *inp = in; - const char *inend = in + inlen; - char **outp = out; - char **outend = out + outlen; - - while (inp != inend) { - size_t len; - char *s; - if (outp == outend) { - errno = ENOSPC; - goto err; - } - len = (unsigned char)*inp; - ++inp; - if (len > (size_t)(inend - inp)) { - errno = EINVAL; - goto err; - } - s = malloc(len + 1); - if (s == NULL) { - goto err; - } - memcpy(s, inp, len); - inp += len; - s[len] = '\0'; - *outp = s; - ++outp; - } - return outp - out; -err: - { - int errno_old = errno; - while (out != outp) { - free(*out); - ++out; - } - errno = errno_old; - } - return -1; -} - - It is important that the length checks always have the form len > (size_t)(inend - inp), where len is a variable of type size_t which denotes the total number of bytes which are about to be read or written next. In general, it is not safe to fold multiple such checks into one, as in len1 + len2 > (size_t)(inend - inp), because the expression on the left can overflow or wrap around (see Section 1.1.3, “Recommendations for integer arithmetic”), and it no longer reflects the number of bytes to be processed. - Recommendations for integer arithmetic1.1.3. Recommendations for integer arithmetic - Overflow in signed integer arithmetic is undefined. This means that it is not possible to check for overflow after it happened, see Example 1.2, “Incorrect overflow detection in C”. - Example 1.2. Incorrect overflow detection in C -void report_overflow(void); - -int -add(int a, int b) -{ - int result = a + b; - if (a < 0 || b < 0) { - return -1; - } - // The compiler can optimize away the following if statement. - if (result < 0) { - report_overflow(); - } - return result; -} - - The following approaches can be used to check for overflow, without actually causing it. - • - Use a wider type to perform the calculation, check that the result is within bounds, and convert the result to the original type. All intermediate results must be checked in this way. - • - Perform the calculation in the corresponding unsigned type and use bit fiddling to detect the overflow. - • - Compute bounds for acceptable input values which are known to avoid overflow, and reject other values. This is the preferred way for overflow checking on multiplications, see Example 1.3, “Overflow checking for unsigned multiplication”. - Example 1.3. Overflow checking for unsigned multiplication -unsigned -mul(unsigned a, unsigned b) -{ - if (b && a > ((unsigned)-1) / b) { - report_overflow(); - } - return a * b; -} - - Basic arithmetic operations a commutative, so for bounds checks, there are two different but mathematically equivalent expressions. Sometimes, one of the expressions results in better code because parts of it can be reduced to a constant. This applies to overflow checks for multiplication a * b involving a constant a, where the expression is reduced to b > C for some constant C determined at compile time. The other expression, b && a > ((unsigned)-1) / b, is more difficult to optimize at compile time. - - When a value is converted to a signed integer, GCC always chooses the result based on 2's complement arithmetic. This GCC extension (which is also implemented by other compilers) helps a lot when implementing overflow checks. - - Legacy code should be compiled with the -fwrapv GCC option. As a result, GCC will provide 2's complement semantics for integer arithmetic, including defined behavior on integer overflow. - The C standard library1.2. The C standard library - Parts of the C standard library (and the UNIX and GNU extensions) are difficult to use, so you shoud avoid them. - - Please check the applicable documentation before using the recommended replacements. Many of these functions allocate buffers using malloc which your code must deallocate explicitly using free. - Absolutely banned interfaces1.2.1. Absolutely banned interfaces - The functions listed below must not be used because they are almost always unsafe. Use the indicated replacements instead. - • - gets ⟶ fgets - • - getwd ⟶ getcwd or get_current_dir_name - • - readdir_r ⟶ readdir - • - realpath (with a non-NULL second parameter) ⟶ realpath with NULL as the second parameter, or canonicalize_file_name - - The constants listed below must not be used, either. Instead, code must allocate memory dynamically and use interfaces with length checking. - • - NAME_MAX (limit not actually enforced by the kernel) - • - PATH_MAX (limit not actually enforced by the kernel) - • - _PC_NAME_MAX (This limit, returned by the pathconf function, is not enforced by the kernel.) - • - _PC_PATH_MAX (This limit, returned by the pathconf function, is not enforced by the kernel.) - - The following structure members must not be used. - • - f_namemax in struct statvfs (limit not actually enforced by the kernel, see _PC_NAME_MAX above) - Functions to avoid1.2.2. Functions to avoid - The following string manipulation functions can be used securely in principle, but their use should be avoided because they are difficult to use correctly. Calls to these functions can be replaced with asprintf or vasprintf. (For non-GNU targets, these functions are available from Gnulib.) In some cases, the snprintf function might be a suitable replacement, see Section 1.2.3, “String Functions With Explicit Length Arguments”. - • - sprintf - • - strcat - • - strcpy - • - vsprintf - - Use the indicated replacements for the functions below. - • - alloca ⟶ malloc and free (see Section 1.3.2, “alloca and other forms of stack-based allocation”) - • - putenv ⟶ explicit envp argument in process creation (see Section 8.1.3, “Specifying the process environment”) - • - setenv ⟶ explicit envp argument in process creation (see Section 8.1.3, “Specifying the process environment”) - • - strdupa ⟶ strdup and free (see Section 1.3.2, “alloca and other forms of stack-based allocation”) - • - strndupa ⟶ strndup and free (see Section 1.3.2, “alloca and other forms of stack-based allocation”) - • - system ⟶ posix_spawn or fork/execve/ (see Section 8.1.2, “Bypassing the shell”) - • - unsetenv ⟶ explicit envp argument in process creation (see Section 8.1.3, “Specifying the process environment”) - String Functions With Explicit Length Arguments1.2.3. String Functions With Explicit Length Arguments - The snprintf function provides a way to construct a string in a statically-sized buffer. (If the buffer size is dynamic, use asprintf instead.) - -char fraction[30]; -snprintf(fraction, sizeof(fraction), "%d/%d", numerator, denominator); - - The second argument to the snprintf should always be the size of the buffer in the first argument (which should be a character array). Complex pointer and length arithmetic can introduce errors and nullify the security benefits of snprintf. If you need to construct a string iteratively, by repeatedly appending fragments, consider constructing the string on the heap, increasing the buffer with realloc as needed. (snprintf does not support overlapping the result buffer with argument strings.) - - If you use vsnprintf (or snprintf) with a format string which is not a constant, but a function argument, it is important to annotate the function with a format function attribute, so that GCC can warn about misuse of your function (see Example 1.4, “The format function attribute”). - Example 1.4. The format function attribute -void log_format(const char *format, ...) __attribute__((format(printf, 1, 2))); - -void -log_format(const char *format, ...) -{ - char buf[1000]; - va_list ap; - va_start(ap, format); - vsnprintf(buf, sizeof(buf), format, ap); - va_end(ap); - log_string(buf); -} - - There are other functions which operator on NUL-terminated strings and take a length argument which affects the number of bytes written to the destination: strncpy, strncat, and stpncpy. These functions do not ensure that the result string is NUL-terminated. For strncpy, NUL termination can be added this way: - -char buf[10]; -strncpy(buf, data, sizeof(buf)); -buf[sizeof(buf) - 1] = '\0'; - - Some systems support strlcpy and strlcat functions which behave this way, but these functions are not part of GNU libc. Using snprintf with a suitable format string is a simple (albeit slightly slower) replacement. - Memory allocators1.3. Memory allocatorsmalloc and related functions1.3.1. malloc and related functions - The C library interfaces for memory allocation are provided by malloc, free and realloc, and the calloc function. In addition to these generic functions, there are derived functions such as strdup which perform allocation using malloc internally, but do not return untyped heap memory (which could be used for any object). - - The C compiler knows about these functions and can use their expected behavior for optimizations. For instance, the compiler assumes that an existing pointer (or a pointer derived from an existing pointer by arithmetic) will not point into the memory area returned by malloc. - - If the allocation fails, realloc does not free the old pointer. Therefore, the idiom ptr = realloc(ptr, size); is wrong because the memory pointed to by ptr leaks in case of an error. - 1.3.1.1. Use-after-free errors - After free, the pointer is invalid. Further pointer dereferences are not allowed (and are usually detected by valgrind). Less obvious is that any use of the old pointer value is not allowed, either. In particular, comparisons with any other pointer (or the null pointer) are undefined according to the C standard. - - The same rules apply to realloc if the memory area cannot be enlarged in-place. For instance, the compiler may assume that a comparison between the old and new pointer will always return false, so it is impossible to detect movement this way. - 1.3.1.2. Handling memory allocation errors - Recovering from out-of-memory errors is often difficult or even impossible. In these cases, malloc and other allocation functions return a null pointer. Dereferencing this pointer lead to a crash. Such dereferences can even be exploitable for code execution if the dereference is combined with an array subscript. - - In general, if you cannot check all allocation calls and handle failure, you should abort the program on allocation failure, and not rely on the null pointer dereference to terminate the process. See Section 9.1, “Recommendations for manually written decoders” for related memory allocation concerns. - alloca and other forms of stack-based allocation1.3.2. alloca and other forms of stack-based allocation - Allocation on the stack is risky because stack overflow checking is implicit. There is a guard page at the end of the memory area reserved for the stack. If the program attempts to read from or write to this guard page, a SIGSEGV signal is generated and the program typically terminates. - - This is sufficient for detecting typical stack overflow situations such as unbounded recursion, but it fails when the stack grows in increments larger than the size of the guard page. In this case, it is possible that the stack pointer ends up pointing into a memory area which has been allocated for a different purposes. Such misbehavior can be exploitable. - - A common source for large stack growth are calls to alloca and related functions such as strdupa. These functions should be avoided because of the lack of error checking. (They can be used safely if the allocated size is less than the page size (typically, 4096 bytes), but this case is relatively rare.) Additionally, relying on alloca makes it more difficult to reorgnize the code because it is not allowed to use the pointer after the function calling alloca has returned, even if this function has been inlined into its caller. - - Similar concerns apply to variable-length arrays (VLAs), a feature of the C99 standard which started as a GNU extension. For large objects exceeding the page size, there is no error checking, either. - - In both cases, negative or very large sizes can trigger a stack-pointer wraparound, and the stack pointer and end up pointing into caller stack frames, which is fatal and can be exploitable. - - If you want to use alloca or VLAs for performance reasons, consider using a small on-stack array (less than the page size, large enough to fulfill most requests). If the requested size is small enough, use the on-stack array. Otherwise, call malloc. When exiting the function, check if malloc had been called, and free the buffer as needed. - Array allocation1.3.3. Array allocation - When allocating arrays, it is important to check for overflows. The calloc function performs such checks. - - If malloc or realloc is used, the size check must be written manually. For instance, to allocate an array of n elements of type T, check that the requested size is not greater than n / sizeof(T). - Custom memory allocators1.3.4. Custom memory allocators - Custom memory allocates come in two forms: replacements for malloc, and completely different interfaces for memory management. Both approaches can reduce the effectiveness of valgrind and similar tools, and the heap corruption detection provided by GNU libc, so they should be avoided. - - Memory allocators are difficult to write and contain many performance and security pitfalls. - • - When computing array sizes or rounding up allocation requests (to the next allocation granularity, or for alignment purposes), checks for arithmetic overflow are required. - • - Size computations for array allocations need overflow checking. See Section 1.3.3, “Array allocation”. - • - It can be difficult to beat well-tuned general-purpose allocators. In micro-benchmarks, pool allocators can show huge wins, and size-specific pools can reduce internal fragmentation. But often, utilization of individual pools is poor, and - Conservative garbage collection1.3.5. Conservative garbage collection - Garbage collection can be an alternative to explicit memory management using malloc and free. The Boehm-Dehmers-Weiser allocator can be used from C programs, with minimal type annotations. Performance is competitive with malloc on 64-bit architectures, especially for multi-threaded programs. The stop-the-world pauses may be problematic for some real-time applications, though. - - However, using a conservative garbage collector may reduce opertunities for code reduce because once one library in a program uses garbage collection, the whole process memory needs to be subject to it, so that no pointers are missed. The Boehm-Dehmers-Weiser collector also reserves certain signals for internal use, so it is not fully transparent to the rest of the program. - Chapter 2.Chapter 2. The C++ Programming LanguageThe C++ Programming LanguageThe core language2.1. The core language - C++ includes a large subset of the C language. As far as the C subset is used, the recommendations in Chapter 1, The C Programming Language apply. - Array allocation with operator new[]2.1.1. Array allocation with operator new[] - For very large values of n, an expression like new T[n] can return a pointer to a heap region which is too small. In other words, not all array elements are actually backed with heap memory reserved to the array. Current GCC versions generate code that performs a computation of the form sizeof(T) * size_t(n) + cookie_size, where cookie_size is currently at most 8. This computation can overflow, and GCC-generated code does not detect this. - - The std::vector template can be used instead an explicit array allocation. (The GCC implementation detects overflow internally.) - - If there is no alternative to operator new[], code which allocates arrays with a variable length must check for overflow manually. For the new T[n] example, the size check could be n || (n > 0 && n > (size_t(-1) - 8) / sizeof(T)). (See Section 1.1.3, “Recommendations for integer arithmetic”.) If there are additional dimensions (which must be constants according to the C++ standard), these should be included as factors in the divisor. - - These countermeasures prevent out-of-bounds writes and potential code execution. Very large memory allocations can still lead to a denial of service. Section 9.1, “Recommendations for manually written decoders” contains suggestions for mitigating this problem when processing untrusted data. - - See Section 1.3.3, “Array allocation” for array allocation advice for C-style memory allocation. - Overloading2.1.2. Overloading - Do not overload functions with versions that have different security characteristics. For instance, do not implement a function strcat which works on std::string arguments. Similarly, do not name methods after such functions. - ABI compatibility and preparing for security updates2.1.3. ABI compatibility and preparing for security updates - A stable binary interface (ABI) is vastly preferred for security updates. Without a stable ABI, all reverse dependencies need recompiling, which can be a lot of work and could even be impossible in some cases. Ideally, a security update only updates a single dynamic shared object, and is picked up automatically after restarting affected processes. - - Outside of extremely performance-critical code, you should ensure that a wide range of changes is possible without breaking ABI. Some very basic guidelines are: - • - Avoid inline functions. - • - Use the pointer-to-implementation idiom. - • - Try to avoid templates. Use them if the increased type safety provides a benefit to the programmer. - • - Move security-critical code out of templated code, so that it can be patched in a central place if necessary. - - The KDE project publishes a document with more extensive guidelines on ABI-preserving changes to C++ code, Policies/Binary Compatibility Issues With C++11 http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ (d-pointer refers to the pointer-to-implementation idiom). - C++0X and C++11 support2.1.4. C++0X and C++11 support - GCC offers different language compatibility modes: - • - -std=c++98 for the original 1998 C++ standard - • - -std=c++03 for the 1998 standard with the changes from the TR1 technical report - • - -std=c++11 for the 2011 C++ standard. This option should not be used. - • - -std=c++0x for several different versions of C++11 support in development, depending on the GCC version. This option should not be used. - - For each of these flags, there are variants which also enable GNU extensions (mostly language features also found in C99 or C11): -std=gnu++98, -std=gnu++03, -std=gnu++11. Again, -std=gnu++11 should not be used. - - If you enable C++11 support, the ABI of the standard C++ library libstdc++ will change in subtle ways. Currently, no C++ libraries are compiled in C++11 mode, so if you compile your code in C++11 mode, it will be incompatible with the rest of the system. Unfortunately, this is also the case if you do not use any C++11 features. Currently, there is no safe way to enable C++11 mode (except for freestanding applications). - - The meaning of C++0X mode changed from GCC release to GCC release. Earlier versions were still ABI-compatible with C++98 mode, but in the most recent versions, switching to C++0X mode activates C++11 support, with its compatibility problems. - - Some C++11 features (or approximations thereof) are available with TR1 support, that is, with -std=c++03 or -std=gnu++03 and in the <tr1/*> header files. This includes std::tr1::shared_ptr (from <tr1/memory>) and std::tr1::function (from <tr1/functional>). For other C++11 features, the Boost C++ library contains replacements. - The C++ standard library2.2. The C++ standard library - The C++ standard library includes most of its C counterpart by reference, see Section 1.2, “The C standard library”. - Containers and operator[]2.2.1. Containers and operator[] - Many containers similar to std::vector provide both operator[](size_type) and a member function at(size_type). This applies to std::vector itself, std::array, std::string and other instances of std::basic_string. - - operator[](size_type) is not required by the standard to perform bounds checking (and the implementation in GCC does not). In contrast, at(size_type) must perform such a check. Therefore, in code which is not performance-critical, you should prefer at(size_type) over operator[](size_type), even though it is slightly more verbose. - Chapter 3.Chapter 3. The Python Programming LanguageThe Python Programming Language - Python provides memory safety by default, so low-level security vulnerabilities are rare and typically needs fixing the Python interpreter or standard library itself. - - Other sections with Python-specific advice include: - • - Chapter 7, Temporary files - • - Section 8.1, “Safe process creation” - • - Chapter 9, Serialization and Deserialization, in particular Section 9.3, “Library support for deserialization” - • - Section 10.2, “Randomness” - Dangerous standard library features3.1. Dangerous standard library features - Some areas of the standard library, notably the ctypes module, do not provide memory safety guarantees comparable to the rest of Python. If such functionality is used, the advice in Section 1.1, “The core language” should be followed. - Run-time compilation and code generation3.2. Run-time compilation and code generation - The following Python functions and statements related to code execution should be avoided: - • - compile - • - eval - • - exec - • - execfile - - If you need to parse integers or floating point values, use the int and float functions instead of eval. Sandboxing untrusted Python code does not work reliably. - Sandboxing3.3. Sandboxing - The rexec Python module cannot safely sandbox untrusted code and should not be used. The standard CPython implementation is not suitable for sandboxing. - Part II. Specific Programming TasksPart II. Specific Programming TasksChapter 4.Chapter 4. Library DesignLibrary Design - Throught this section, the term client code refers to applications and other libraries using the library. - State management4.1. State management - - Global state4.1.1. Global state - Global state should be avoided. - - If this is impossible, the global state must be protected with a lock. For C/C++, you can use the pthread_mutex_lock and pthread_mutex_unlock functions without linking against -lpthread because the system provides stubs for non-threaded processes. - - For compatibility with fork, these locks should be acquired and released in helpers registered with pthread_atfork. This function is not available without -lpthread, so you need to use dlsym or a weak symbol to obtain its address. - - If you need fork protection for other reasons, you should store the process ID and compare it to the value returned by getpid each time you access the global state. (getpid is not implemented as a system call and is fast.) If the value changes, you know that you have to re-create the state object. (This needs to be combined with locking, of course.) - Handles4.1.2. Handles - Library state should be kept behind a curtain. Client code should receive only a handle. In C, the handle can be a pointer to an incomplete struct. In C++, the handle can be a pointer to an abstract base class, or it can be hidden using the pointer-to-implementation idiom. - - The library should provide functions for creating and destroying handles. (In C++, it is possible to use virtual destructors for the latter.) Consistency between creation and destruction of handles is strongly recommended: If the client code created a handle, it is the responsibility of the client code to destroy it. (This is not always possible or convenient, so sometimes, a transfer of ownership has to happen.) - - Using handles ensures that it is possible to change the way the library represents state in a way that is transparent to client code. This is important to facilitate security updates and many other code changes. - - It is not always necessary to protect state behind a handle with a lock. This depends on the level of thread safety the library provides. - Object orientation4.2. Object orientation - Classes should be either designed as base classes, or it should be impossible to use them as base classes (like final classes in Java). Classes which are not designed for inheritance and are used as base classes nevertheless create potential maintenance hazards because it is difficult to predict how client code will react when calls to virtual methods are added, reordered or removed. - - Virtual member functions can be used as callbacks. See Section 4.3, “Callbacks” for some of the challenges involved. - Callbacks4.3. Callbacks - Higher-order code is difficult to analyze for humans and computers alike, so it should be avoided. Often, an iterator-based interface (a library function which is called repeatedly by client code and returns a stream of events) leads to a better design which is easier to document and use. - - If callbacks are unavoidable, some guidelines for them follow. - - In modern C++ code, std::function objects should be used for callbacks. - - In older C++ code and in C code, all callbacks must have an additional closure parameter of type void *, the value of which can be specified by client code. If possible, the value of the closure parameter should be provided by client code at the same time a specific callback is registered (or specified as a function argument). If a single closure parameter is shared by multiple callbacks, flexibility is greatly reduced, and conflicts between different pieces of client code using the same library object could be unresolvable. In some cases, it makes sense to provide a de-registration callback which can be used to destroy the closure parameter when the callback is no longer used. - - Callbacks can throw exceptions or call longjmp. If possible, all library objects should remain in a valid state. (All further operations on them can fail, but it should be possible to deallocate them without causing resource leaks.) - - The presence of callbacks raises the question if functions provided by the library are reentrant. Unless a library was designed for such use, bad things will happen if a callback function uses functions in the same library (particularly if they are invoked on the same objects and manipulate the same state). When the callback is invoked, the library can be in an inconsistent state. Reentrant functions are more difficult to write than thread-safe functions (by definition, simple locking would immediately lead to deadlocks). It is also difficult to decide what to do when destruction of an object which is currently processing a callback is requested. - Process attributes4.4. Process attributes - Several attributes are global and affect all code in the process, not just the library that manipulates them. - • - environment variables (see Section 8.3.1, “Accessing environment variables”) - • - umask - • - user IDs, group IDs and capabilities - • - current working directory - • - signal handlers, signal masks and signal delivery - • - file locks (especially fcntl locks behave in surprising ways, not just in a multi-threaded environment) - - Library code should avoid manipulating these global process attributes. It should not rely on environment variables, umask, the current working directory and signal masks because these attributes can be inherted from an untrusted source. - - In addition, there are obvious process-wide aspects such as the virtual memory layout, the set of open files and dynamic shared objects, but with the exception of shared objects, these can be manipulated in a relatively isolated way. - Chapter 5.Chapter 5. File Descriptor ManagementFile Descriptor Management - File descriptors underlie all input/output mechanisms offered by the system. They are used to implementation the FILE *-based functions found in <stdio.h>, and all the file and network communication facilities provided by the Python and Java environments are eventually implemented in them. - - File descriptors are small, non-negative integers in userspace, and are backed on the kernel side with complicated data structures which can sometimes grow very large. - Closing descriptors5.1. Closing descriptors - If a descriptor is no longer used by a program and is not closed explicitly, its number cannot be reused (which is problematic in itself, see Section 5.3, “Dealing with the select limit”), and the kernel resources are not freed. Therefore, it is important to close all descriptors at the earlierst point in time possible, but not earlier. - Error handling during descriptor close5.1.1. Error handling during descriptor close - The close system call is always successful in the sense that the passed file descriptor is never valid after the function has been called. However, close still can return an error, for example if there was a file system failure. But this error is not very useful because the absence of an error does not mean that all caches have been emptied and previous writes have been made durable. Programs which need such guarantees must open files with O_SYNC or use fsync or fdatasync, and may also have to fsync the directory containing the file. - Closing descriptors and race conditions5.1.2. Closing descriptors and race conditions - Unlike process IDs, which are recycle only gradually, the kernel always allocates the lowest unused file descriptor when a new descriptor is created. This means that in a multi-threaded program which constantly opens and closes file descriptors, descriptors are reused very quickly. Unless descriptor closing and other operations on the same file descriptor are synchronized (typically, using a mutex), there will be race coniditons and I/O operations will be applied to the wrong file descriptor. - - Sometimes, it is necessary to close a file descriptor concurrently, while another thread might be about to use it in a system call. In order to support this, a program needs to create a single special file descriptor, one on which all I/O operations fail. One way to achieve this is to use socketpair, close one of the descriptors, and call shutdown(fd, SHUTRDWR) on the other. - - When a descriptor is closed concurrently, the program does not call close on the descriptor. Instead it program uses dup2 to replace the descriptor to be closed with the dummy descriptor created earlier. This way, the kernel will not reuse the descriptor, but it will carry out all other steps associated with calling a descriptor (for instance, if the descriptor refers to a stream socket, the peer will be notified). - - This is just a sketch, and many details are missing. Additional data structures are needed to determine when it is safe to really close the descriptor, and proper locking is required for that. - Lingering state after close5.1.3. Lingering state after close - By default, closing a stream socket returns immediately, and the kernel will try to send the data in the background. This means that it is impossible to implement accurate accounting of network-related resource utilization from userspace. - - The SO_LINGER socket option alters the behavior of close, so that it will return only after the lingering data has been processed, either by sending it to the peer successfully, or by discarding it after the configured timeout. However, there is no interface which could perform this operation in the background, so a separate userspace thread is needed for each close call, causing scalability issues. - - Currently, there is no application-level countermeasure which applies universally. Mitigation is possible with iptables (the connlimit match type in particular) and specialized filtering devices for denial-of-service network traffic. - - These problems are not related to the TIME_WAIT state commonly seen in netstat output. The kernel automatically expires such sockets if necessary. - Preventing file descriptor leaks to child processes5.2. Preventing file descriptor leaks to child processes - Child processes created with fork share the initial set of file descriptors with their parent process. By default, file descriptors are also preserved if a new process image is created with execve (or any of the other functions such as system or posix_spawn). - - Usually, this behavior is not desirable. There are two ways to turn it off, that is, to prevent new process images from inheriting the file descriptors in the parent process: - • - Set the close-on-exec flag on all newly created file descriptors. Traditionally, this flag is controlled by the FD_CLOEXEC flag, using F_GETFD and F_SETFD operations of the fcntl function. - - However, in a multi-threaded process, there is a race condition: a subprocess could have been created between the time the descriptor was created and the FD_CLOEXEC was set. Therefore, many system calls which create descriptors (such as open and openat) now accept the O_CLOEXEC flag (SOCK_CLOEXEC for socket and socketpair), which cause the FD_CLOEXEC flag to be set for the file descriptor in an atomic fashion. In addition, a few new systems calls were introduced, such as pipe2 and dup3. - - The downside of this approach is that every descriptor needs to receive special treatment at the time of creation, otherwise it is not completely effective. - • - After calling fork, but before creating a new process image with execve, all file descriptors which the child process will not need are closed. - - Traditionally, this was implemented as a loop over file descriptors ranging from 3 to 255 and later 1023. But this is only an approximatio because it is possible to create file descriptors outside this range easily (see Section 5.3, “Dealing with the select limit”). Another approach reads /proc/self/fd and closes the unexpected descriptors listed there, but this approach is much slower. - - At present, environments which care about file descriptor leakage implement the second approach. OpenJDK 6 and 7 are among them. - Dealing with the select limit5.3. Dealing with the select limit - By default, a user is allowed to open only 1024 files in a single process, but the system administrator can easily change this limit (which is necessary for busy network servers). However, there is another restriction which is more difficult to overcome. - - The select function only supports a maximum of FD_SETSIZE file descriptors (that is, the maximum permitted value for a file descriptor is FD_SETSIZE - 1, usually 1023.) If a process opens many files, descriptors may exceed such limits. It is impossible to query such descriptors using select. - - If a library which creates many file descriptors is used in the same process as a library which uses select, at least one of them needs to be changed. Calls to select can be replaced with calls to poll or another event handling mechanism. - - Alternatively, the library with high descriptor usage can relocate descriptors above the FD_SETSIZE limit using the following procedure. - • - Create the file descriptor fd as usual, preferably with the O_CLOEXEC flag. - • - Before doing anything else with the descriptor fd, invoke: - - int newfd = fcntl(fd, F_DUPFD_CLOEXEC, (long)FD_SETSIZE); -• - Check that newfd result is non-negative, otherwise close fd and report an error, and return. - • - Close fd and continue to use newfd. - - The new descriptor has been allocated above the FD_SETSIZE. Even though this algorithm is racy in the sense that the FD_SETSIZE first descriptors could fill up, a very high degree of physical parallelism is required before this becomes a problem. - Chapter 6.Chapter 6. File system manipulationFile system manipulation - In this chapter, we discuss general file system manipulation, with a focus on access files and directories to which an other, potentially untrusted user has write access. - - Temporary files are covered in their own chapter, Chapter 7, Temporary files. - Working with files and directories owned by other users6.1. Working with files and directories owned by other users - Sometimes, it is necessary to operate on files and directories owned by other (potentially untrusted) users. For example, a system administrator could remove the home directory of a user, or a package manager could update a file in a directory which is owned by an application-specific user. This differs from accessing the file system as a specific user; see Section 6.2, “Accessing the file system as a different user”. - - Accessing files across trust boundaries faces several challenges, particularly if an entire directory tree is being traversed: - 1. - Another user might add file names to a writable directory at any time. This can interfere with file creation and the order of names returned by readdir. - 2. - Merely opening and closing a file can have side effects. For instance, an automounter can be triggered, or a tape device rewound. Opening a file on a local file system can block indefinitely, due to mandatory file locking, unless the O_NONBLOCK flag is specified. - 3. - Hard links and symbolic links can redirect the effect of file system operations in unexpected ways. The O_NOFOLLOW and AT_SYMLINK_NOFOLLOW variants of system calls only affected final path name component. - 4. - The structure of a directory tree can change. For example, the parent directory of what used to be a subdirectory within the directory tree being processed could suddenly point outside that directory tree. - - Files should always be created with the O_CREAT and O_EXCL flags, so that creating the file will fail if it already exists. This guards against the unexpected appearance of file names, either due to creation of a new file, or hard-linking of an existing file. In multi-threaded programs, rather than manipulating the umask, create the files with mode 000 if possible, and adjust it afterwards with fchmod. - - To avoid issues related to symbolic links and directory tree restructuring, the “at” variants of system calls have to be used (that is, functions like openat, fchownat, fchmodat, and unlinkat, together with O_NOFOLLOW or AT_SYMLINK_NOFOLLOW). Path names passed to these functions must have just a single component (that is, without a slash). When descending, the descriptors of parent directories must be kept open. The missing opendirat function can be emulated with openat (with an O_DIRECTORY flag, to avoid opening special files with side effects), followed by fdopendir. - - If the “at” functions are not available, it is possible to emulate them by changing the current directory. (Obviously, this only works if the process is not multi-threaded.) fchdir has to be used to change the current directory, and the descriptors of the parent directories have to be kept open, just as with the “at”-based approach. chdir("...") is unsafe because it might ascend outside the intended directory tree. - - This “at” function emulation is currently required when manipulating extended attributes. In this case, the lsetxattr function can be used, with a relative path name consisting of a single component. This also applies to SELinux contexts and the lsetfilecon function. - - Currently, it is not possible to avoid opening special files and changes to files with hard links if the directory containing them is owned by an untrusted user. (Device nodes can be hard-linked, just as regular files.) fchmodat and fchownat affect files whose link count is greater than one. But opening the files, checking that the link count is one with fstat, and using fchmod and fchown on the file descriptor may have unwanted side effects, due to item 2 above. When creating directories, it is therefore important to change the ownership and permissions only after it has been fully created. Until that point, file names are stable, and no files with unexpected hard links can be introduced. - - Similarly, when just reading a directory owned by an untrusted user, it is currently impossible to reliably avoid opening special files. - - There is no workaround against the instability of the file list returned by readdir. Concurrent modification of the directory can result in a list of files being returned which never actually existed on disk. - - Hard links and symbolic links can be safely deleted using unlinkat without further checks because deletion only affects the name within the directory tree being processed. - Accessing the file system as a different user6.2. Accessing the file system as a different user - This section deals with access to the file system as a specific user. This is different from accessing files and directories owned by a different, potentially untrusted user; see Section 6.2, “Accessing the file system as a different user”. - - One approach is to spawn a child process which runs under the target user and group IDs (both effective and real IDs). Note that this child process can block indefinitely, even when processing regular files only. For example, a special FUSE file system could cause the process to hang in uninterruptible sleep inside a stat system call. - - An existing process could change its user and group ID using setfsuid and setfsgid. (These functions are preferred over seteuid and setegid because they do not allow the impersonated user to send signals to the process.) These functions are not thread safe. In multi-threaded processes, these operations need to be performed in a single-threaded child process. Unexpected blocking may occur as well. - - It is not recommended to try to reimplement the kernel permission checks in user space because the required checks are complex. It is also very difficult to avoid race conditions during path name resolution. - File system limits6.3. File system limits - For historical reasons, there are preprocessor constants such as PATH_MAX, NAME_MAX. However, on most systems, the length of canonical path names (absolute path names with all symbolic links resolved, as returned by realpath or canonicalize_file_name) can exceed PATH_MAX bytes, and individual file name components can be longer than NAME_MAX. This is also true of the _PC_PATH_MAX and _PC_NAME_MAX values returned by pathconf, and the f_namemax member of struct statvfs. Therefore, these constants should not be used. This is also reason why the readdir_r should never be used (instead, use readdir). - - You should not write code in a way that assumes that there is an upper limit on the number of subdirectories of a directory, the number of regular files in a directory, or the link count of an inode. - File system features6.4. File system features - Not all file systems support all features. This makes it very difficult to write general-purpose tools for copying files. For example, a copy operation intending to preserve file permissions will generally fail when copying to a FAT file system. - • - Some file systems are case-insensitive. Most should be case-preserving, though. - • - Name length limits vary greatly, from eight to thousands of bytes. Path length limits differ as well. Most systems impose an upper bound on path names passed to the kernel, but using relative path names, it is possible to create and access files whose absolute path name is essentially of unbounded length. - • - Some file systems do not store names as fairly unrestricted byte sequences, as it has been traditionally the case on GNU systems. This means that some byte sequences (outside the POSIX safe character set) are not valid names. Conversely, names of existing files may not be representable as byte sequences, and the files are thus inaccessible on GNU systems. Some file systems perform Unicode canonicalization on file names. These file systems preserve case, but reading the name of a just-created file using readdir might still result in a different byte sequence. - • - Permissions and owners are not universally supported (and SUID/SGID bits may not be available). For example, FAT file systems assign ownership based on a mount option, and generally mark all files as executable. Any attempt to change permissions would result in an error. - • - Non-regular files (device nodes, FIFOs) are not generally available. - • - Only on some file systems, files can have holes, that is, not all of their contents is backed by disk storage. - • - ioctl support (even fairly generic functionality such as FIEMAP for discovering physical file layout and holes) is file-system-specific. - • - Not all file systems support extended attributes, ACLs and SELinux metadata. Size and naming restriction on extended attributes vary. - • - Hard links may not be supported at all (FAT) or only within the same directory (AFS). Symbolic links may not be available, either. Reflinks (hard links with copy-on-write semantics) are still very rare. Recent systems restrict creation of hard links to users which own the target file or have read/write access to it, but older systems do not. - • - Renaming (or moving) files using rename can fail (even when stat indicates that the source and target directories are located on the same file system). This system call should work if the old and new paths are located in the same directory, though. - • - Locking semantics vary among file systems. This affects advisory and mandatory locks. For example, some network file systems do not allow deleting files which are opened by any process. - • - Resolution of time stamps varies from two seconds to nanoseconds. Not all time stamps are available on all file systems. File creation time (birth time) is not exposed over the stat/fstat interface, even if stored by the file system. - Checking free space6.5. Checking free space - The statvfs and fstatvfs functions allow programs to examine the number of available blocks and inodes, through the members f_bfree, f_bavail, f_ffree, and f_favail of struct statvfs. Some file systems return fictional values in the f_ffree and f_favail fields, so the only reliable way to discover if the file system still has space for a file is to try to create it. The f_bfree field should be reasonably accurate, though. - Chapter 7.Chapter 7. Temporary filesTemporary files - In this chapter, we describe how to create temporary files and directories, how to remove them, and how to work with programs which do not create files in ways that a safe with a shared directory for temporary files. General file system manipulation is treated in a separate chapter, Chapter 6, File system manipulation. - - Secure creation of temporary files has four different aspects. - • - The location of the directory for temporary files must be obtained in a secure manner (that is, untrusted environment variables must be ignored, see Section 8.3.1, “Accessing environment variables”). - • - A new file must be created. Reusing an existing file must be avoided (the /tmp race condition). This is tricky because traditionally, system-wide temporary directories shared by all users are used. - • - The file must be created in a way that makes it impossible for other users to open it. - • - The descriptor for the temporary file should not leak to subprocesses. - - All functions mentioned below will take care of these aspects. - - Traditionally, temporary files are often used to reduce memory usage of programs. More and more systems use RAM-based file systems such as tmpfs for storing temporary files, to increase performance and decrease wear on Flash storage. As a result, spooling data to temporary files does not result in any memory savings, and the related complexity can be avoided if the data is kept in process memory. - Obtaining the location of temporary directory7.1. Obtaining the location of temporary directory - Some functions below need the location of a directory which stores temporary files. For C/C++ programs, use the following steps to obtain that directory: - • - Use secure_getenv to obtain the value of the TMPDIR environment variable. If it is set, convert the path to a fully-resolved absolute path, using realpath(path, NULL). Check if the new path refers to a directory and is writeable. In this case, use it as the temporary directory. - • - Fall back to /tmp. - - In Python, you can use the tempfile.tempdir variable. - - Java does not support SUID/SGID programs, so you can use the java.lang.System.getenv(String) method to obtain the value of the TMPDIR environment variable, and follow the two steps described above. (Java's default directory selection does not honor TMPDIR.) - Named temporary files7.2. Named temporary files - The mkostemp function creates a named temporary file. You should specify the O_CLOEXEC flag to avoid file descriptor leaks to subprocesses. (Applications which do not use multiple threads can also use mkstemp, but libraries should use mkostemp.) For determining the directory part of the file name pattern, see Section 7.1, “Obtaining the location of temporary directory”. - - The file is not removed automatically. It is not safe to rename or delete the file before processing, or transform the name in any way (for example, by adding a file extension). If you need multiple temporary files, call mkostemp multiple times. Do not create additional file names derived from the name provided by a previous mkostemp call. However, it is safe to close the descriptor returned by mkostemp and reopen the file using the generated name. - - The Python class tempfile.NamedTemporaryFile provides similar functionality, except that the file is deleted automatically by default. Note that you may have to use the file attribute to obtain the actual file object because some programming interfaces cannot deal with file-like objects. The C function mkostemp is also available as tempfile.mkstemp. - - In Java, you can use the java.io.File.createTempFile(String, String, File) function, using the temporary file location determined according to Section 7.1, “Obtaining the location of temporary directory”. Do not use java.io.File.deleteOnExit() to delete temporary files, and do not register a shutdown hook for each temporary file you create. In both cases, the deletion hint cannot be removed from the system if you delete the temporary file prior to termination of the VM, causing a memory leak. - Temporary files without names7.3. Temporary files without names - The tmpfile function creates a temporary file and immediately deletes it, while keeping the file open. As a result, the file lacks a name and its space is deallocated as soon as the file descriptor is closed (including the implicit close when the process terminates). This avoids cluttering the temporary directory with orphaned files. - - Alternatively, if the maximum size of the temporary file is known beforehand, the fmemopen function can be used to create a FILE * object which is backed by memory. - - In Python, unnamed temporary files are provided by the tempfile.TemporaryFile class, and the tempfile.SpooledTemporaryFile class provides a way to avoid creation of small temporary files. - - Java does not support unnamed temporary files. - Temporary directories7.4. Temporary directories - The mkdtemp function can be used to create a temporary directory. (For determining the directory part of the file name pattern, see Section 7.1, “Obtaining the location of temporary directory”.) The directory is not automatically removed. In Python, this function is available as tempfile.mkdtemp. In Java 7, temporary directories can be created using the java.nio.file.Files.createTempDirectory(Path, String, FileAttribute...) function. - - When creating files in the temporary directory, use automatically generated names, e.g., derived from a sequential counter. Files with externally provided names could be picked up in unexpected contexts, and crafted names could actually point outside of the tempoary directory (due to directory traversal). - - Removing a directory tree in a completely safe manner is complicated. Unless there are overriding performance concerns, the rm program should be used, with the -rf and -- options. - Compensating for unsafe file creation7.5. Compensating for unsafe file creation - There are two ways to make a function or program which excepts a file name safe for use with temporary files. See Section 8.1, “Safe process creation”, for details on subprocess creation. - • - Create a temporary directory and place the file there. If possible, run the program in a subprocess which uses the temporary directory as its current directory, with a restricted environment. Use generated names for all files in that temporary directory. (See Section 7.4, “Temporary directories”.) - • - Create the temporary file and pass the generated file name to the function or program. This only works if the function or program can cope with a zero-length existing file. It is safe only under additional assumptions: - • - The function or program must not create additional files whose name is derived from the specified file name or are otherwise predictable. - • - The function or program must not delete the file before processing it. - • - It must not access any existing files in the same directory. - - It is often difficult to check whether these additional assumptions are matched, therefore this approach is not recommended. - Chapter 8.Chapter 8. ProcessesProcessesSafe process creation8.1. Safe process creation - This section describes how to create new child processes in a safe manner. In addition to the concerns addressed below, there is the possibility of file descriptor leaks, see Section 5.2, “Preventing file descriptor leaks to child processes”. - Obtaining the program path and the command line template8.1.1. Obtaining the program path and the command line template - The name and path to the program being invoked should be hard-coded or controlled by a static configuration file stored at a fixed location (at an file system absolute path). The same applies to the template for generating the command line. - - The configured program name should be an absolute path. If it is a relative path, the contents of the PATH must be obtained in s secure manner (see Section 8.3.1, “Accessing environment variables”). If the PATH variable is not set or untrusted, the safe default /bin:/usr/bin must be used. - - If too much flexibility is provided here, it may allow invocation of arbitrary programs without proper authorization. - Bypassing the shell8.1.2. Bypassing the shell - Child processes should be created without involving the system shell. - - For C/C++, system should not be used. The posix_spawn function can be used instead, or a combination fork and execve. (In some cases, it may be preferable to use vfork or the Linux-specific clone system call instead of fork.) - - In Python, the subprocess module bypasses the shell by default (when the shell keyword argument is not set to true). os.system should not be used. - - The Java class java.lang.ProcessBuilder can be used to create subprocesses without interference from the system shell. - Portability notice - On Windows, there is no argument vector, only a single argument string. Each application is responsible for parsing this string into an argument vector. There is considerable variance among the quoting style recognized by applications. Some of them expand shell wildcards, others do not. Extensive application-specific testing is required to make this secure. - - Note that some common applications (notably ssh) unconditionally introduce the use of a shell, even if invoked directly without a shell. It is difficult to use these applications in a secure manner. In this case, untrusted data should be supplied by other means. For example, standard input could be used, instead of the command line. - Specifying the process environment8.1.3. Specifying the process environment - Child processes should be created with a minimal set of environment variables. This is absolutely essential if there is a trust transition involved, either when the parent process was created, or during the creation of the child process. - - In C/C++, the environment should be constructed as an array of strings and passed as the envp argument to posix_spawn or execve. The functions setenv, unsetenv and putenv should not be used. They are not thread-safe and suffer from memory leaks. - - Python programs need to specify a dict for the the env argument of the subprocess.Popen constructor. The Java class java.lang.ProcessBuilder provides a environment() method, which returns a map that can be manipulated. - - The following list provides guidelines for selecting the set of environment variables passed to the child process. - • - PATH should be initialized to /bin:/usr/bin. - • - USER and HOME can be inhereted from the parent process environment, or they can be initialized from the pwent structure for the user. - • - The DISPLAY and XAUTHORITY variables should be passed to the subprocess if it is an X program. Note that this will typically not work across trust boundaries because XAUTHORITY refers to a file with 0600 permissions. - • - The location-related environment variables LANG, LANGUAGE, LC_ADDRESS, LC_ALL, LC_COLLATE, LC_CTYPE, LC_IDENTIFICATION, LC_MEASUREMENT, LC_MESSAGES, LC_MONETARY, LC_NAME, LC_NUMERIC, LC_PAPER, LC_TELEPHONE and LC_TIME can be passed to the subprocess if present. - • - The called process may need application-specific environment variables, for example for passing passwords. (See Section 8.1.5, “Passing secrets to subprocesses”.) - • - All other environment variables should be dropped. Names for new environment variables should not be accepted from untrusted sources. - Robust argument list processing8.1.4. Robust argument list processing - When invoking a program, it is sometimes necessary to include data from untrusted sources. Such data should be check against embedded NUL characters because the system APIs will sliently truncate argument strings at the first NUL character. - - The following recommendations assume that the program being invoked uses GNU-style option processing using getopt_long. This convention is widely used, but it is just that, and individual programs might interpret a command line in a different way. - - If the untrusted data has to go into an option, use the --option-name=VALUE syntax, placing the option and its value into the same command line argument. This avoids any potential confusion if the data starts with -. - - For positional arguments, terminate the option list with a single -- marker after the last option, and include the data at the right position. The -- marker terminates option processing, and the data will not be treated as an option even if it starts with a dash. - Passing secrets to subprocesses8.1.5. Passing secrets to subprocesses - The command line (the name of the program and its argument) of a running process is traditionally available to all local users. The called program can overwrite this information, but only after it has run for a bit of time, during which the information may have been read by other processes. However, on Linux, the process environment is restricted to the user who runs the process. Therefore, if you need a convenient way to pass a password to a child process, use an environment variable, and not a command line argument. (See Section 8.1.3, “Specifying the process environment”.) - Portability notice - On some UNIX-like systems (notably Solaris), environment variables can be read by any system user, just like command lines. - - If the environment-based approach cannot be used due to portability concerns, the data can be passed on standard input. Some programs (notably gpg) use special file descriptors whose numbers are specified on the command line. Temporary files are an option as well, but they might give digital forensics access to sensitive data (such as passphrases) because it is difficult to safely delete them in all cases. - Handling child process termination8.2. Handling child process termination - When child processes terminate, the parent process is signalled. A stub of the terminated processes (a zombie, shown as <defunct> by ps) is kept around until the status information is collected (reaped) by the parent process. Over the years, several interfaces for this have been invented: - • - The parent process calls wait, waitpid, waitid, wait3 or wait4, without specifying a process ID. This will deliver any matching process ID. This approach is typically used from within event loops. - • - The parent process calls waitpid, waitid, or wait4, with a specific process ID. Only data for the specific process ID is returned. This is typically used in code which spawns a single subprocess in a synchronous manner. - • - The parent process installs a handler for the SIGCHLD signal, using sigaction, and specifies to the SA_NOCLDWAIT flag. This approach could be used by event loops as well. - - None of these approaches can be used to wait for child process terminated in a completely thread-safe manner. The parent process might execute an event loop in another thread, which could pick up the termination signal. This means that libraries typically cannot make free use of child processes (for example, to run problematic code with reduced privileges in a separate address space). - - At the moment, the parent process should explicitly wait for termination of the child process using waitpid or waitpid, and hope that the status is not collected by an event loop first. - SUID/SGID processes8.3. SUID/SGID processes - Programs can be marked in the file system to indicate to the kernel that a trust transition should happen if the program is run. The SUID file permission bit indicates that an executable should run with the effective user ID equal to the owner of the executable file. Similarly, with the SGID bit, the effective group ID is set to the group of the executable file. - - Linux supports fscaps, which can grant additional capabilities to a process in a finer-grained manner. Additional mechanisms can be provided by loadable security modules. - - When such a trust transition has happened, the process runs in a potentially hostile environment. Additional care is necessary not to rely on any untrusted information. These concerns also apply to libraries which can be linked into such processes. - Accessing environment variables8.3.1. Accessing environment variables - The following steps are required so that a program does not accidentally pick up untrusted data from environment variables. - • - Compile your C/C++ sources with -D_GNU_SOURCE. The Autoconf macro AC_GNU_SOURCE ensures this. - • - Check for the presence of the secure_getenv and __secure_getenv function. The Autoconf directive AC_CHECK_FUNCS([__secure_getenv secure_getenv]) performs these checks. - • - Arrange for a proper definition of the secure_getenv function. See Example 8.1, “Obtaining a definition for secure_getenv”. - • - Use secure_getenv instead of getenv to obtain the value of critical environment variables. secure_getenv will pretend the variable has not bee set if the process environment is not trusted. - - Critical environment variables are debugging flags, configuration file locations, plug-in and log file locations, and anything else that might be used to bypass security restrictions or cause a privileged process to behave in an unexpected way. - - Either the secure_getenv function or the __secure_getenv is available from GNU libc. - Example 8.1. Obtaining a definition for secure_getenv - -#include <stdlib.h> - -#ifndef HAVE_SECURE_GETENV -# ifdef HAVE__SECURE_GETENV -# define secure_getenv __secure_getenv -# else -# error neither secure_getenv nor __secure_getenv are available -# endif -#endif - -Daemons8.4. Daemons - Background processes providing system services (daemons) need to decouple themselves from the controlling terminal and the parent process environment: - • - Fork. - • - In the child process, call setsid. The parent process can simply exit (using _exit, to avoid running clean-up actions twice). - • - In the child process, fork again. Processing continues in the child process. Again, the parent process should just exit. - • - Replace the descriptors 0, 1, 2 with a descriptor for /dev/null. Logging should be redirected to syslog. - - Older instructions for creating daemon processes recommended a call to umask(0). This is risky because it often leads to world-writable files and directories, resulting in security vulnerabilities such as arbitrary process termination by untrusted local users, or log file truncation. If the umask needs setting, a restrictive value such as 027 or 077 is recommended. - - Other aspects of the process environment may have to changed as well (environment variables, signal handler disposition). - - It is increasingly common that server processes do not run as background processes, but as regular foreground process under a supervising master process (such as systemd). Server processes should offer a command line option which disables forking and replacement of the standard output and standard error streams. Such an option is also useful for debugging. - Semantics of command line arguments8.5. Semantics of command line arguments - After process creation and option processing, it is up to the child process to interpret the arguments. Arguments can be file names, host names, or URLs, and many other things. URLs can refer to the local network, some server on the Internet, or to the local file system. Some applications even accept arbitrary code in arguments (for example, python with the -c option). - - Similar concerns apply to environment variables, the contents of the current directory and its subdirectories. - - Consequently, careful analysis is required if it is safe to pass untrusted data to another program. - fork as a primitive for parallelism8.6. fork as a primitive for parallelism - A call to fork which is not immediately followed by a call to execve (perhaps after rearranging and closing file descriptors) is typically unsafe, especially from a library which does not control the state of the entire process. Such use of fork should be replaced with proper child processes or threads. - Chapter 9.Chapter 9. Serialization and DeserializationSerialization and Deserialization - Protocol decoders and file format parsers are often the most-exposed part of an application because they are exposed with little or no user interaction and before any authentication and security checks are made. They are also difficult to write robustly in languages which are not memory-safe. - Recommendations for manually written decoders9.1. Recommendations for manually written decoders - For C and C++, the advice in Section 1.1.2, “Recommendations for pointers and array handling” applies. In addition, avoid non-character pointers directly into input buffers. Pointer misalignment causes crashes on some architectures. - - When reading variable-sized objects, do not allocate large amounts of data solely based on the value of a size field. If possible, grow the data structure as more data is read from the source, and stop when no data is available. This helps to avoid denial-of-service attacks where little amounts of input data results in enormous memory allocations during decoding. Alternatively, you can impose reasonable bounds on memory allocations, but some protocols do not permit this. - Protocol design9.2. Protocol design - Binary formats with explicit length fields are more difficult to parse robustly than those where the length of dynamically-sized elements is derived from sentinel values. A protocol which does not use length fields and can be written in printable ASCII characters simplifies testing and debugging. However, binary protocols with length fields may be more efficient to parse. - Library support for deserialization9.3. Library support for deserialization - For some languages, generic libraries are available which allow to serialize and deserialize user-defined objects. The deserialization part comes in one of two flavors, depending on the library. The first kind uses type information in the data stream to control which objects are instantiated. The second kind uses type definitions supplied by the programmer. The first one allows arbitrary object instantiation, the second one generally does not. - - The following serialization frameworks are in the first category, are known to be unsafe, and must not be used for untrusted data: - • - Python's pickle and cPickle modules - • - Perl's Storable package - • - Java serialization (java.io.ObjectInputStream) - • - PHP serialization (unserialize) - • - Most implementations of YAML - - When using a type-directed deserialization format where the types of the deserialized objects are specified by the programmer, make sure that the objects which can be instantiated cannot perform any destructive actions in their destructors, even when the data members have been manipulated. - - JSON decoders do not suffer from this problem. But you must not use the eval function to parse JSON objects in Javascript; even with the regular expression filter from RFC 4627, there are still information leaks remaining. - XML serialization9.4. XML serialization - - External references9.4.1. External references - XML documents can contain external references. They can occur in various places. - • - In the DTD declaration in the header of an XML document: - -<!DOCTYPE html PUBLIC - "-//W3C//DTD XHTML 1.0 Transitional//EN" - "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> -• - In a namespace declaration: - -<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> -• - In an entity defintion: - -<!ENTITY sys SYSTEM "http://www.example.com/ent.xml"> -<!ENTITY pub PUBLIC "-//Example//Public Entity//EN" - "http://www.example.com/pub-ent.xml"> -• - In a notation: - -<!NOTATION not SYSTEM "../not.xml"> - - Originally, these external references were intended as unique identifiers, but by many XML implementations, they are used for locating the data for the referenced element. This causes unwanted network traffic, and may disclose file system contents or otherwise unreachable network resources, so this functionality should be disabled. - - Depending on the XML library, external referenced might be processed not just when parsing XML, but also when generating it. - Entity expansion9.4.2. Entity expansion - When external DTD processing is disabled, an internal DTD subset can still contain entity definitions. Entity declarations can reference other entities. Some XML libraries expand entities automatically, and this processing cannot be switched off in some places (such as attribute values or content models). Without limits on the entity nesting level, this expansion results in data which can grow exponentially in length with size of the input. (If there is a limit on the nesting level, the growth is still polynomial, unless further limits are imposed.) - - Consequently, the processing internal DTD subsets should be disabled if possible, and only trusted DTDs should be processed. If a particular XML application does not permit such restrictions, then application-specific limits are called for. - XInclude processing9.4.3. XInclude processing - XInclude processing can reference file and network resources and include them into the document, much like external entity references. When parsing untrusted XML documents, XInclude processing should be truned off. - - XInclude processing is also fairly complex and may pull in support for the XPointer and XPath specifications, considerably increasing the amount of code required for XML processing. - Algorithmic complexity of XML validation9.4.4. Algorithmic complexity of XML validation - DTD-based XML validation uses regular expressions for content models. The XML specification requires that content models are deterministic, which means that efficient validation is possible. However, some implementations do not enforce determinism, and require exponential (or just polynomial) amount of space or time for validating some DTD/document combinations. - - XML schemas and RELAX NG (via the xsd: prefix) directly support textual regular expressions which are not required to be deterministic. - Using Expat for XML parsing9.4.5. Using Expat for XML parsing - By default, Expat does not try to resolve external IDs, so no steps are required to block them. However, internal entity declarations are processed. Installing a callback which stops parsing as soon as such entities are encountered disables them, see Example 9.1, “Disabling XML entity processing with Expat”. Expat does not perform any validation, so there are no problems related to that. - Example 9.1. Disabling XML entity processing with Expat -// Stop the parser when an entity declaration is encountered. -static void -EntityDeclHandler(void *userData, - const XML_Char *entityName, int is_parameter_entity, - const XML_Char *value, int value_length, - const XML_Char *base, const XML_Char *systemId, - const XML_Char *publicId, const XML_Char *notationName) -{ - XML_StopParser((XML_Parser)userData, XML_FALSE); -} - - This handler must be installed when the XML_Parser object is created (Example 9.2, “Creating an Expat XML parser”). - Example 9.2. Creating an Expat XML parser -XML_Parser parser = XML_ParserCreate("UTF-8"); -if (parser == NULL) { - fprintf(stderr, "XML_ParserCreate failed\n"); - close(fd); - exit(1); -} -// EntityDeclHandler needs a reference to the parser to stop -// parsing. -XML_SetUserData(parser, parser); -// Disable entity processing, to inhibit entity expansion. -XML_SetEntityDeclHandler(parser, EntityDeclHandler); - - It is also possible to reject internal DTD subsets altogeher, using a suitable XML_StartDoctypeDeclHandler handler installed with XML_SetDoctypeDeclHandler. - Using OpenJDK for XML parsing and validation9.4.6. Using OpenJDK for XML parsing and validation - OpenJDK contains facilities for DOM-based, SAX-based, and StAX-based document parsing. Documents can be validated against DTDs or XML schemas. - - The approach taken to deal with entity expansion differs from the general recommendation in Section 9.4.2, “Entity expansion”. We enable the the feature flag javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, which enforces heuristic restrictions on the number of entity expansions. Note that this flag alone does not prevent resolution of external references (system IDs or public IDs), so it is slightly misnamed. - - In the following sections, we use helper classes to prevent external ID resolution. - Example 9.3. Helper class to prevent DTD external entity resolution in OpenJDK -class NoEntityResolver implements EntityResolver { - @Override - public InputSource resolveEntity(String publicId, String systemId) - throws SAXException, IOException { - // Throwing an exception stops validation. - throw new IOException(String.format( - "attempt to resolve \"%s\" \"%s\"", publicId, systemId)); - } -} -Example 9.4. Helper class to prevent schema resolution in OpenJDK -class NoResourceResolver implements LSResourceResolver { - @Override - public LSInput resolveResource(String type, String namespaceURI, - String publicId, String systemId, String baseURI) { - // Throwing an exception stops validation. - throw new RuntimeException(String.format( - "resolution attempt: type=%s namespace=%s " + - "publicId=%s systemId=%s baseURI=%s", - type, namespaceURI, publicId, systemId, baseURI)); - } -} - - Example 9.5, “Java imports for OpenJDK XML parsing” shows the imports used by the examples. - Example 9.5. Java imports for OpenJDK XML parsing -import javax.xml.XMLConstants; -import javax.xml.parsers.DocumentBuilder; -import javax.xml.parsers.DocumentBuilderFactory; -import javax.xml.parsers.ParserConfigurationException; -import javax.xml.parsers.SAXParser; -import javax.xml.parsers.SAXParserFactory; -import javax.xml.transform.dom.DOMSource; -import javax.xml.transform.sax.SAXSource; -import javax.xml.validation.Schema; -import javax.xml.validation.SchemaFactory; -import javax.xml.validation.Validator; - -import org.w3c.dom.Document; -import org.w3c.dom.ls.LSInput; -import org.w3c.dom.ls.LSResourceResolver; -import org.xml.sax.EntityResolver; -import org.xml.sax.ErrorHandler; -import org.xml.sax.InputSource; -import org.xml.sax.SAXException; -import org.xml.sax.SAXParseException; -import org.xml.sax.XMLReader; -9.4.6.1. DOM-based XML parsing and DTD validation in OpenJDK - This approach produces a org.w3c.dom.Document object from an input stream. Example 9.6, “DOM-based XML parsing in OpenJDK” use the data from the java.io.InputStream instance in the inputStream variable. - Example 9.6. DOM-based XML parsing in OpenJDK -DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); -// Impose restrictions on the complexity of the DTD. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// Turn on validation. -// This step can be omitted if validation is not desired. -factory.setValidating(true); - -// Parse the document. -DocumentBuilder builder = factory.newDocumentBuilder(); -builder.setEntityResolver(new NoEntityResolver()); -builder.setErrorHandler(new Errors()); -Document document = builder.parse(inputStream); - - External entity references are prohibited using the NoEntityResolver class in Example 9.3, “Helper class to prevent DTD external entity resolution in OpenJDK”. Because external DTD references are prohibited, DTD validation (if enabled) will only happen against the internal DTD subset embedded in the XML document. - - To validate the document against an external DTD, use a javax.xml.transform.Transformer class to add the DTD reference to the document, and an entity resolver which whitelists this external reference. - 9.4.6.2. XML Schema validation in OpenJDK - Example 9.7, “SAX-based validation against an XML schema in OpenJDK” shows how to validate a document against an XML Schema, using a SAX-based approach. The XML data is read from an java.io.InputStream in the inputStream variable. - Example 9.7. SAX-based validation against an XML schema in OpenJDK -SchemaFactory factory = SchemaFactory.newInstance( - XMLConstants.W3C_XML_SCHEMA_NS_URI); - -// This enables restrictions on the schema and document -// complexity. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// This prevents resource resolution by the schema itself. -// If the schema is trusted and references additional files, -// this line must be omitted, otherwise loading these files -// will fail. -factory.setResourceResolver(new NoResourceResolver()); - -Schema schema = factory.newSchema(schemaFile); -Validator validator = schema.newValidator(); - -// This prevents external resource resolution. -validator.setResourceResolver(new NoResourceResolver()); - -validator.validate(new SAXSource(new InputSource(inputStream))); - - The NoResourceResolver class is defined in Example 9.4, “Helper class to prevent schema resolution in OpenJDK”. - - If you need to validate a document against an XML schema, use the code in Example 9.6, “DOM-based XML parsing in OpenJDK” to create the document, but do not enable validation at this point. Then use Example 9.8, “Validation of a DOM document against an XML schema in OpenJDK” to perform the schema-based validation on the org.w3c.dom.Document instance document. - Example 9.8. Validation of a DOM document against an XML schema in OpenJDK -SchemaFactory factory = SchemaFactory.newInstance( - XMLConstants.W3C_XML_SCHEMA_NS_URI); - -// This enables restrictions on schema complexity. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// The following line prevents resource resolution -// by the schema itself. -factory.setResourceResolver(new NoResourceResolver()); - -Schema schema = factory.newSchema(schemaFile); - -Validator validator = schema.newValidator(); - -// This prevents external resource resolution. -validator.setResourceResolver(new NoResourceResolver()); -validator.validate(new DOMSource(document)); -Protocol Encoders9.5. Protocol Encoders - For protocol encoders, you should write bytes to a buffer which grows as needed, using an exponential sizing policy. Explicit lengths can be patched in later, once they are known. Allocating the required number of bytes upfront typically requires separate code to compute the final size, which must be kept in sync with the actual encoding step, or vulnerabilities may result. In multi-threaded code, parts of the object being deserialized might change, so that the computed size is out of date. - - You should avoid copying data directly from a received packet during encoding, disregarding the format. Propagating malformed data could enable attacks on other recipients of that data. - - When using C or C++ and copying whole data structures directly into the output, make sure that you do not leak information in padding bytes between fields or at the end of the struct. - Chapter 10.Chapter 10. CryptographyCryptographyPrimitives10.1. Primitives - Chosing from the following cryptographic primitives is recommended: - • - RSA with 2048 bit keys and OAEP - • - AES-128 in CBC mode - • - SHA-256 - • - HMAC-SHA-256 - • - HMAC-SHA-1 - - Other cryptographic algorithms can be used if they are required for interoperability with existing software: - • - RSA with key sizes larger than 1024 and legacy padding - • - AES-192 - • - AES-256 - • - 3DES (triple DES, with two or three 56 bit keys) - • - RC4 (but very, very strongly discouraged) - • - SHA-1 - • - HMAC-MD5 - Important - These primitives are difficult to use in a secure way. Custom implementation of security protocols should be avoided. For protecting confidentiality and integrity of network transmissions, TLS should be used (Chapter 12, Transport Layer Security). - Randomness10.2. Randomness - The following facilities can be used to generate unpredictable and non-repeating values. When these functions are used without special safeguards, each individual rnadom value should be at least 12 bytes long. - • - PK11_GenerateRandom in the NSS library (usable for high data rates) - • - RAND_bytes in the OpenSSL library (usable for high data rates) - • - gnutls_rnd in GNUTLS, with GNUTLS_RND_RANDOM as the first argument (usable for high data rates) - • - java.security.SecureRandom in Java (usable for high data rates) - • - os.urandom in Python - • - Reading from the /dev/urandom character device - - All these functions should be non-blocking, and they should not wait until physical randomness becomes available. (Some cryptography providers for Java can cause java.security.SecureRandom to block, however.) Those functions which do not obtain all bits directly from /dev/urandom are suitable for high data rates because they do not deplete the system-wide entropy pool. - Difficult to use API - Both RAND_bytes and PK11_GenerateRandom have three-state return values (with conflicting meanings). Careful error checking is required. Please review the documentation when using these functions. - - Other sources of randomness should be considered predictable. - - Generating randomness for cryptographic keys in long-term use may need different steps and is best left to cryptographic libraries. - Part III. Implementing Security FeaturesPart III. Implementing Security FeaturesChapter 11.Chapter 11. Authentication and AuthorizationAuthentication and AuthorizationAuthenticating servers11.1. Authenticating servers - When connecting to a server, a client has to make sure that it is actually talking to the server it expects. There are two different aspects, securing the network path, and making sure that the expected user runs the process on the target host. There are several ways to ensure that: - • - The server uses a TLS certificate which is valid according to the web browser public key infrastructure, and the client verifies the certificate and the host name. - • - The server uses a TLS certificate which is expectedby the client (perhaps it is stored in a configuration file read by the client). In this case, no host name checking is required. - • - On Linux, UNIX domain sockets (of the PF_UNIX protocol family, sometimes called PF_LOCAL) are restricted by file system permissions. If the server socket path is not world-writable, the server identity cannot be spoofed by local users. - • - Port numbers less than 1024 (trusted ports) can only be used by root, so if a UDP or TCP server is running on the local host and it uses a trusted port, its identity is assured. (Not all operating systems enforce the trusted ports concept, and the network might not be trusted, so it is only useful on the local system.) - - TLS (Chapter 12, Transport Layer Security) is the recommended way for securing connections over untrusted networks. - - If the server port number is 1024 is higher, a local user can impersonate the process by binding to this socket, perhaps after crashing the real server by exploiting a denial-of-service vulnerability. - Host-based authentication11.2. Host-based authentication - Host-based authentication uses access control lists (ACLs) to accept or deny requests from clients. Thsis authentication method comes in two flavors: IP-based (or, more generally, address-based) and name-based (with the name coming from DNS or /etc/hosts). IP-based ACLs often use prefix notation to extend access to entire subnets. Name-based ACLs sometimes use wildcards for adding groups of hosts (from entire DNS subtrees). (In the SSH context, host-based authentication means something completely different and is not covered in this section.) - - Host-based authentication trust the network and may not offer sufficient granularity, so it has to be considered a weak form of authentication. On the other hand, IP-based authentication can be made extremely robust and can be applied very early in input processing, so it offers an opportunity for significantly reducing the number of potential attackers for many services. - - The names returned by gethostbyaddr and getnameinfo functions cannot be trusted. (DNS PTR records can be set to arbitrary values, not just names belong to the address owner.) If these names are used for ACL matching, a forward lookup using gethostbyaddr or getaddrinfo has to be performed. The name is only valid if the original address is found among the results of the forward lookup (double-reverse lookup). - - An empty ACL should deny all access (deny-by-default). If empty ACLs permits all access, configuring any access list must switch to deny-by-default for all unconfigured protocols, in both name-based and address-based variants. - - Similarly, if an address or name is not matched by the list, it should be denied. However, many implementations behave differently, so the actual behavior must be documented properly. - - IPv6 addresses can embed IPv4 addresses. There is no universally correct way to deal with this ambiguity. The behavior of the ACL implementation should be documented. - UNIX domain socket authentication11.3. UNIX domain socket authentication - UNIX domain sockets (with address family AF_UNIX or AF_LOCAL) are restricted to the local host and offer a special authentication mechanism: credentials passing. - - Nowadays, most systems support the SO_PEERCRED (Linux) or LOCAL_PEERCRED (FreeBSD) socket options, or the getpeereid (other BSDs, MacOS X). These interfaces provide direct access to the (effective) user ID on the other end of a domain socket connect, without cooperation from the other end. - - Historically, credentials passing was implemented using ancillary data in the sendmsg and recvmsg functions. On some systems, only credentials data that the peer has explicitly sent can be received, and the kernel checks the data for correctness on the sending side. This means that both peers need to deal with ancillary data. Compared to that, the modern interfaces are easier to use. Both sets of interfaces vary considerably among UNIX-like systems, unfortunately. - - If you want to authenticate based on supplementary groups, you should obtain the user ID using one of these methods, and look up the list of supplementary groups using getpwuid (or getpwuid_r) and getgrouplist. Using the PID and information from /proc/PID/status is prone to race conditions and insecure. - AF_NETLINK authentication of origin11.4. AF_NETLINK authentication of origin - Netlink messages are used as a high-performance data transfer mechanism between the kernel and the userspace. Traditionally, they are used to exchange information related to the network statck, such as routing table entries. - - When processing Netlink messages from the kernel, it is important to check that these messages actually originate from the kernel, by checking that the port ID (or PID) field nl_pid in the sockaddr_nl structure is 0. (This structure can be obtained using recvfrom or recvmsg, it is different from the nlmsghdr structure.) The kernel does not prevent other processes from sending unicast Netlink messages, but the nl_pid field in the sender's socket address will be non-zero in such cases. - - Applications should not use AF_NETLINK sockets as an IPC mechanism among processes, but prefer UNIX domain sockets for this tasks. - Chapter 12.Chapter 12. Transport Layer SecurityTransport Layer Security - Transport Layer Security (TLS, formerly Secure Sockets Layer/SSL) is the recommended way to to protect integrity and confidentiality while data is transferred over an untrusted network connection, and to identify the endpoint. - Common Pitfalls12.1. Common Pitfalls - TLS implementations are difficult to use, and most of them lack a clean API design. The following sections contain implementation-specific advice, and some generic pitfalls are mentioned below. - • - Most TLS implementations have questionable default TLS cipher suites. Most of them enable anonymous Diffie-Hellman key exchange (but we generally want servers to authenticate themselves). Many do not disable ciphers which are subject to brute-force attacks because of restricted key lengths. Some even disable all variants of AES in the default configuration. - - When overriding the cipher suite defaults, it is recommended to disable all cipher suites which are not present on a whitelist, instead of simply enabling a list of cipher suites. This way, if an algorithm is disabled by default in the TLS implementation in a future security update, the application will not re-enable it. - • - The name which is used in certificate validation must match the name provided by the user or configuration file. No host name canonicalization or IP address lookup must be performed. - • - The TLS handshake has very poor performance if the TCP Nagle algorithm is active. You should switch on the TCP_NODELAY socket option (at least for the duration of the handshake), or use the Linux-specific TCP_CORK option. - Example 12.1. Deactivating the TCP Nagle algorithm -const int val = 1; -int ret = setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &val, sizeof(val)); -if (ret < 0) { - perror("setsockopt(TCP_NODELAY)"); - exit(1); -} -• - Implementing proper session resumption decreases handshake overhead considerably. This is important if the upper-layer protocol uses short-lived connections (like most application of HTTPS). - • - Both client and server should work towards an orderly connection shutdown, that is send close_notify alerts and respond to them. This is especially important if the upper-layer protocol does not provide means to detect connection truncation (like some uses of HTTP). - • - When implementing a server using event-driven programming, it is important to handle the TLS handshake properly because it includes multiple network round-trips which can block when an ordinary TCP accept would not. Otherwise, a client which fails to complete the TLS handshake for some reason will prevent the server from handling input from other clients. - • - Unlike regular file descriptors, TLS connections cannot be passed between processes. Some TLS implementations add additional restrictions, and TLS connections generally cannot be used across fork function calls (see Section 8.6, “fork as a primitive for parallelism”). - OpenSSL Pitfalls12.1.1. OpenSSL Pitfalls - Some OpenSSL function use tri-state return values. Correct error checking is extremely important. Several functions return int values with the following meaning: - • - The value 1 indicates success (for example, a successful signature verification). - • - The value 0 indicates semantic failure (for example, a signature verification which was unsuccessful because the signing certificate was self-signed). - • - The value -1 indicates a low-level error in the system, such as failure to allocate memory using malloc. - - Treating such tri-state return values as booleans can lead to security vulnerabilities. Note that some OpenSSL functions return boolean results or yet another set of status indicators. Each function needs to be checked individually. - - Recovering precise error information is difficult. Example 12.2, “Obtaining OpenSSL error codes” shows how to obtain a more precise error code after a function call on an SSL object has failed. However, there are still cases where no detailed error information is available (e.g., if SSL_shutdown fails due to a connection teardown by the other end). - Example 12.2. Obtaining OpenSSL error codes -static void __attribute__((noreturn)) -ssl_print_error_and_exit(SSL *ssl, const char *op, int ret) -{ - int subcode = SSL_get_error(ssl, ret); - switch (subcode) { - case SSL_ERROR_NONE: - fprintf(stderr, "error: %s: no error to report\n", op); - break; - case SSL_ERROR_WANT_READ: - case SSL_ERROR_WANT_WRITE: - case SSL_ERROR_WANT_X509_LOOKUP: - case SSL_ERROR_WANT_CONNECT: - case SSL_ERROR_WANT_ACCEPT: - fprintf(stderr, "error: %s: invalid blocking state %d\n", op, subcode); - break; - case SSL_ERROR_SSL: - fprintf(stderr, "error: %s: TLS layer problem\n", op); - case SSL_ERROR_SYSCALL: - fprintf(stderr, "error: %s: system call failed: %s\n", op, strerror(errno)); - break; - case SSL_ERROR_ZERO_RETURN: - fprintf(stderr, "error: %s: zero return\n", op); - } - exit(1); -} - - The OPENSSL_config function is documented to never fail. In reality, it can terminate the entire process if there is a failure accessing the configuration file. An error message is written to standard error, but which might not be visible if the function is called from a daemon process. - - OpenSSL contains two separate ASN.1 DER decoders. One set of decoders operate on BIO handles (the input/output stream abstraction provided by OpenSSL); their decoder function names start with d2i_ and end in _fp or _bio (e.g., d2i_X509_fp or d2i_X509_bio). These decoders must not be used for parsing data from untrusted sources; instead, the variants without the _fp and _bio (e.g., d2i_X509) shall be used. The BIO variants have received considerably less testing and are not very robust. - - For the same reason, the OpenSSL command line tools (such as openssl x509) are generally generally less robust than the actual library code. They use the BIO functions internally, and not the more robust variants. - - The command line tools do not always indicate failure in the exit status of the openssl process. For instance, a verification failure in openssl verify result in an exit status of zero. - - The OpenSSL server and client applications (openssl s_client and openssl s_server) are debugging tools and should never be used as generic clients. For instance, the s_client tool reacts in a surprisign way to lines starting with R and Q. - - OpenSSL allows application code to access private key material over documented interfaces. This can significantly increase the part of the code base which has to undergo security certification. - GNUTLS Pitfalls12.1.2. GNUTLS Pitfalls - libgnutls.so.26 links to libpthread.so.0. Loading the threading library too late causes problems, so the main program should be linked with -lpthread as well. As a result, it can be difficult to use GNUTLS in a plugin which is loaded with the dlopen function. Another side effect is that applications which merely link against GNUTLS (even without actually using it) may incur a substantial overhead because other libraries automatically switch to thread-safe algorithms. - - The gnutls_global_init function must be called before using any functionality provided by the library. This function is not thread-safe, so external locking is required, but it is not clear which lock should be used. Omitting the synchronization does not just lead to a memory leak, as it is suggested in the GNUTLS documentation, but to undefined behavior because there is no barrier that would enforce memory ordering. - - The gnutls_global_deinit function does not actually deallocate all resources allocated by gnutls_global_init. It is currently not thread-safe. Therefore, it is best to avoid calling it altogether. - - The X.509 implementation in GNUTLS is rather lenient. For example, it is possible to create and process X.509 version 1 certificates which carry extensions. These certificates are (correctly) rejected by other implementations. - OpenJDK Pitfalls12.1.3. OpenJDK Pitfalls - The Java cryptographic framework is highly modular. As a result, when you request an object implementing some cryptographic functionality, you cannot be completely sure that you end up with the well-tested, reviewed implementation in OpenJDK. - - OpenJDK (in the source code as published by Oracle) and other implementations of the Java platform require that the system administrator has installed so-called unlimited strength jurisdiction policy files. Without this step, it is not possible to use the secure algorithms which offer sufficient cryptographic strength. Most downstream redistributors of OpenJDK remove this requirement. - - Some versions of OpenJDK use /dev/random as the randomness source for nonces and other random data which is needed for TLS operation, but does not actually require physical randomness. As a result, TLS applications can block, waiting for more bits to become available in /dev/random. - NSS Pitfalls12.1.4. NSS Pitfalls - NSS was not designed to be used by other libraries which can be linked into applications without modifying them. There is a lot of global state. There does not seem to be a way to perform required NSS initialization without race conditions. - - If the NSPR descriptor is in an unexpected state, the SSL_ForceHandshake function can succeed, but no TLS handshake takes place, the peer is not authenticated, and subsequent data is exchanged in the clear. - - NSS disables itself if it detects that the process underwent a fork after the library has been initialized. This behavior is required by the PKCS#11 API specification. - TLS Clients12.2. TLS Clients - Secure use of TLS in a client generally involves all of the following steps. (Individual instructions for specific TLS implementations follow in the next sections.) - • - The client must configure the TLS library to use a set of trusted root certificates. These certificates are provided by the system in /etc/ssl/certs or files derived from it. - • - The client selects sufficiently strong cryptographic primitives and disables insecure ones (such as no-op encryption). Compression and SSL version 2 support must be disabled (including the SSLv2-compatible handshake). - • - The client initiates the TLS connection. The Server Name Indication extension should be used if supported by the TLS implementation. Before switching to the encrypted connection state, the contents of all input and output buffers must be discarded. - • - The client needs to validate the peer certificate provided by the server, that is, the client must check that there is a cryptographically protected chain from a trusted root certificate to the peer certificate. (Depending on the TLS implementation, a TLS handshake can succeed even if the certificate cannot be validated.) - • - The client must check that the configured or user-provided server name matches the peer certificate provided by the server. - - It is safe to provide users detailed diagnostics on certificate validation failures. Other causes of handshake failures and, generally speaking, any details on other errors reported by the TLS implementation (particularly exception tracebacks), must not be divulged in ways that make them accessible to potential attackers. Otherwise, it is possible to create decryption oracles. - Important - Depending on the application, revocation checking (against certificate revocations lists or via OCSP) and session resumption are important aspects of production-quality client. These aspects are not yet covered. - Implementation TLS Clients With OpenSSL12.2.1. Implementation TLS Clients With OpenSSL - In the following code, the error handling is only exploratory. Proper error handling is required for production use, especially in libraries. - - The OpenSSL library needs explicit initialization (see Example 12.3, “OpenSSL library initialization”). - Example 12.3. OpenSSL library initialization -// The following call prints an error message and calls exit() if -// the OpenSSL configuration file is unreadable. -OPENSSL_config(NULL); -// Provide human-readable error messages. -SSL_load_error_strings(); -// Register ciphers. -SSL_library_init(); - - After that, a context object has to be created, which acts as a factory for connection objects (Example 12.4, “OpenSSL client context creation”). We use an explicit cipher list so that we do not pick up any strange ciphers when OpenSSL is upgraded. The actual version requested in the client hello depends on additional restrictions in the OpenSSL library. If possible, you should follow the example code and use the default list of trusted root certificate authorities provided by the system because you would have to maintain your own set otherwise, which can be cumbersome. - Example 12.4. OpenSSL client context creation -// Configure a client connection context. Send a hendshake for the -// highest supported TLS version, and disable compression. -const SSL_METHOD *const req_method = SSLv23_client_method(); -SSL_CTX *const ctx = SSL_CTX_new(req_method); -if (ctx == NULL) { - ERR_print_errors(bio_err); - exit(1); -} -SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_COMPRESSION); - -// Adjust the ciphers list based on a whitelist. First enable all -// ciphers of at least medium strength, to get the list which is -// compiled into OpenSSL. -if (SSL_CTX_set_cipher_list(ctx, "HIGH:MEDIUM") != 1) { - ERR_print_errors(bio_err); - exit(1); -} -{ - // Create a dummy SSL session to obtain the cipher list. - SSL *ssl = SSL_new(ctx); - if (ssl == NULL) { - ERR_print_errors(bio_err); - exit(1); - } - STACK_OF(SSL_CIPHER) *active_ciphers = SSL_get_ciphers(ssl); - if (active_ciphers == NULL) { - ERR_print_errors(bio_err); - exit(1); - } - // Whitelist of candidate ciphers. - static const char *const candidates[] = { - "AES128-GCM-SHA256", "AES128-SHA256", "AES256-SHA256", // strong ciphers - "AES128-SHA", "AES256-SHA", // strong ciphers, also in older versions - "RC4-SHA", "RC4-MD5", // backwards compatibility, supposed to be weak - "DES-CBC3-SHA", "DES-CBC3-MD5", // more backwards compatibility - NULL - }; - // Actually selected ciphers. - char ciphers[300]; - ciphers[0] = '\0'; - for (const char *const *c = candidates; *c; ++c) { - for (int i = 0; i < sk_SSL_CIPHER_num(active_ciphers); ++i) { - if (strcmp(SSL_CIPHER_get_name(sk_SSL_CIPHER_value(active_ciphers, i)), - *c) == 0) { - if (*ciphers) { - strcat(ciphers, ":"); - } - strcat(ciphers, *c); - break; - } - } - } - SSL_free(ssl); - // Apply final cipher list. - if (SSL_CTX_set_cipher_list(ctx, ciphers) != 1) { - ERR_print_errors(bio_err); - exit(1); - } -} - -// Load the set of trusted root certificates. -if (!SSL_CTX_set_default_verify_paths(ctx)) { - ERR_print_errors(bio_err); - exit(1); -} - - A single context object can be used to create multiple connection objects. It is safe to use the same SSL_CTX object for creating connections concurrently from multiple threads, provided that the SSL_CTX object is not modified (e.g., callbacks must not be changed). - - After creating the TCP socket and disabling the Nagle algorithm (per Example 12.1, “Deactivating the TCP Nagle algorithm”), the actual connection object needs to be created, as show in Example 12.4, “OpenSSL client context creation”. If the handshake started by SSL_connect fails, the ssl_print_error_and_exit function from Example 12.2, “Obtaining OpenSSL error codes” is called. - - The certificate_validity_override function provides an opportunity to override the validity of the certificate in case the OpenSSL check fails. If such functionality is not required, the call can be removed, otherwise, the application developer has to implement it. - - The host name passed to the functions SSL_set_tlsext_host_name and X509_check_host must be the name that was passed to getaddrinfo or a similar name resolution function. No host name canonicalization must be performed. The X509_check_host function used in the final step for host name matching is currently only implemented in OpenSSL 1.1, which is not released yet. In case host name matching fails, the function certificate_host_name_override is called. This function should check user-specific certificate store, to allow a connection even if the host name does not match the certificate. This function has to be provided by the application developer. Note that the override must be keyed by both the certificate and the host name. - Example 12.5. Creating a client connection using OpenSSL -// Create the connection object. -SSL *ssl = SSL_new(ctx); -if (ssl == NULL) { - ERR_print_errors(bio_err); - exit(1); -} -SSL_set_fd(ssl, sockfd); - -// Enable the ServerNameIndication extension -if (!SSL_set_tlsext_host_name(ssl, host)) { - ERR_print_errors(bio_err); - exit(1); -} - -// Perform the TLS handshake with the server. -ret = SSL_connect(ssl); -if (ret != 1) { - // Error status can be 0 or negative. - ssl_print_error_and_exit(ssl, "SSL_connect", ret); -} - -// Obtain the server certificate. -X509 *peercert = SSL_get_peer_certificate(ssl); -if (peercert == NULL) { - fprintf(stderr, "peer certificate missing"); - exit(1); -} - -// Check the certificate verification result. Allow an explicit -// certificate validation override in case verification fails. -int verifystatus = SSL_get_verify_result(ssl); -if (verifystatus != X509_V_OK && !certificate_validity_override(peercert)) { - fprintf(stderr, "SSL_connect: verify result: %s\n", - X509_verify_cert_error_string(verifystatus)); - exit(1); -} - -// Check if the server certificate matches the host name used to -// establish the connection. -// FIXME: Currently needs OpenSSL 1.1. -if (X509_check_host(peercert, (const unsigned char *)host, strlen(host), - 0) != 1 - && !certificate_host_name_override(peercert, host)) { - fprintf(stderr, "SSL certificate does not match host name\n"); - exit(1); -} - -X509_free(peercert); - - - The connection object can be used for sending and receiving data, as in Example 12.6, “Using an OpenSSL connection to send and receive data”. It is also possible to create a BIO object and use the SSL object as the underlying transport, using BIO_set_ssl. - Example 12.6. Using an OpenSSL connection to send and receive data -const char *const req = "GET / HTTP/1.0\r\n\r\n"; -if (SSL_write(ssl, req, strlen(req)) < 0) { - ssl_print_error_and_exit(ssl, "SSL_write", ret); -} -char buf[4096]; -ret = SSL_read(ssl, buf, sizeof(buf)); -if (ret < 0) { - ssl_print_error_and_exit(ssl, "SSL_read", ret); -} - - When it is time to close the connection, the SSL_shutdown function needs to be called twice for an orderly, synchronous connection termination (Example 12.7, “Closing an OpenSSL connection in an orderly fashion”). This exchanges close_notify alerts with the server. The additional logic is required to deal with an unexpected close_notify from the server. Note that is necessary to explicitly close the underlying socket after the connection object has been freed. - Example 12.7. Closing an OpenSSL connection in an orderly fashion -// Send the close_notify alert. -ret = SSL_shutdown(ssl); -switch (ret) { -case 1: - // A close_notify alert has already been received. - break; -case 0: - // Wait for the close_notify alert from the peer. - ret = SSL_shutdown(ssl); - switch (ret) { - case 0: - fprintf(stderr, "info: second SSL_shutdown returned zero\n"); - break; - case 1: - break; - default: - ssl_print_error_and_exit(ssl, "SSL_shutdown 2", ret); - } - break; -default: - ssl_print_error_and_exit(ssl, "SSL_shutdown 1", ret); -} -SSL_free(ssl); -close(sockfd); - - Example 12.8, “Closing an OpenSSL connection in an orderly fashion” shows how to deallocate the context object when it is no longer needed because no further TLS connections will be established. - Example 12.8. Closing an OpenSSL connection in an orderly fashion -SSL_CTX_free(ctx); -Implementation TLS Clients With GNUTLS12.2.2. Implementation TLS Clients With GNUTLS - This section describes how to implement a TLS client with full certificate validation (but without certificate revocation checking). Note that the error handling in is only exploratory and needs to be replaced before production use. - - The GNUTLS library needs explicit initialization: - -gnutls_global_init(); - - Failing to do so can result in obscure failures in Base64 decoding. See Section 12.1.2, “GNUTLS Pitfalls” for additional aspects of initialization. - - Before setting up TLS connections, a credentials objects has to be allocated and initialized with the set of trusted root CAs (Example 12.9, “Initializing a GNUTLS credentials structure”). - Example 12.9. Initializing a GNUTLS credentials structure -// Load the trusted CA certificates. -gnutls_certificate_credentials_t cred = NULL; -int ret = gnutls_certificate_allocate_credentials (&cred); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_certificate_allocate_credentials: %s\n", - gnutls_strerror(ret)); - exit(1); -} -// gnutls_certificate_set_x509_system_trust needs GNUTLS version 3.0 -// or newer, so we hard-code the path to the certificate store -// instead. -static const char ca_bundle[] = "/etc/ssl/certs/ca-bundle.crt"; -ret = gnutls_certificate_set_x509_trust_file - (cred, ca_bundle, GNUTLS_X509_FMT_PEM); -if (ret == 0) { - fprintf(stderr, "error: no certificates found in: %s\n", ca_bundle); - exit(1); -} -if (ret < 0) { - fprintf(stderr, "error: gnutls_certificate_set_x509_trust_files(%s): %s\n", - ca_bundle, gnutls_strerror(ret)); - exit(1); -} - - After the last TLS connection has been closed, this credentials object should be freed: - -gnutls_certificate_free_credentials(cred); - - During its lifetime, the credentials object can be used to initialize TLS session objects from multiple threads, provided that it is not changed. - - Once the TCP connection has been established, the Nagle algorithm should be disabled (see Example 12.1, “Deactivating the TCP Nagle algorithm”). After that, the socket can be associated with a new GNUTLS session object. The previously allocated credentials object provides the set of root CAs. The NORMAL set of cipher suites and protocols provides a reasonable default. Then the TLS handshake must be initiated. This is shown in Example 12.10, “Establishing a TLS client connection using GNUTLS”. - Example 12.10. Establishing a TLS client connection using GNUTLS -// Create the session object. -gnutls_session_t session; -ret = gnutls_init(&session, GNUTLS_CLIENT); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_init: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Configure the cipher preferences. -const char *errptr = NULL; -ret = gnutls_priority_set_direct(session, "NORMAL", &errptr); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_priority_set_direct: %s\n" - "error: at: \"%s\"\n", gnutls_strerror(ret), errptr); - exit(1); -} - -// Install the trusted certificates. -ret = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, cred); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_credentials_set: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Associate the socket with the session object and set the server -// name. -gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t)(uintptr_t)sockfd); -ret = gnutls_server_name_set(session, GNUTLS_NAME_DNS, - host, strlen(host)); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_server_name_set: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Establish the session. -ret = gnutls_handshake(session); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_handshake: %s\n", - gnutls_strerror(ret)); - exit(1); -} - - After the handshake has been completed, the server certificate needs to be verified (Example 12.11, “Verifying a server certificate using GNUTLS”). In the example, the user-defined certificate_validity_override function is called if the verification fails, so that a separate, user-specific trust store can be checked. This function call can be omitted if the functionality is not needed. - Example 12.11. Verifying a server certificate using GNUTLS -// Obtain the server certificate chain. The server certificate -// itself is stored in the first element of the array. -unsigned certslen = 0; -const gnutls_datum_t *const certs = - gnutls_certificate_get_peers(session, &certslen); -if (certs == NULL || certslen == 0) { - fprintf(stderr, "error: could not obtain peer certificate\n"); - exit(1); -} - -// Validate the certificate chain. -unsigned status = (unsigned)-1; -ret = gnutls_certificate_verify_peers2(session, &status); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_certificate_verify_peers2: %s\n", - gnutls_strerror(ret)); - exit(1); -} -if (status != 0 && !certificate_validity_override(certs[0])) { - gnutls_datum_t msg; -#if GNUTLS_VERSION_AT_LEAST_3_1_4 - int type = gnutls_certificate_type_get (session); - ret = gnutls_certificate_verification_status_print(status, type, &out, 0); -#else - ret = -1; -#endif - if (ret == 0) { - fprintf(stderr, "error: %s\n", msg.data); - gnutls_free(msg.data); - exit(1); - } else { - fprintf(stderr, "error: certificate validation failed with code 0x%x\n", - status); - exit(1); - } -} - - In the next step (Example 12.12, “Matching the server host name and certificate in a GNUTLS client”, the certificate must be matched against the host name (note the unusual return value from gnutls_x509_crt_check_hostname). Again, an override function certificate_host_name_override is called. Note that the override must be keyed to the certificate and the host name. The function call can be omitted if the override is not needed. - Example 12.12. Matching the server host name and certificate in a GNUTLS client -// Match the peer certificate against the host name. -// We can only obtain a set of DER-encoded certificates from the -// session object, so we have to re-parse the peer certificate into -// a certificate object. -gnutls_x509_crt_t cert; -ret = gnutls_x509_crt_init(&cert); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_x509_crt_init: %s\n", - gnutls_strerror(ret)); - exit(1); -} -// The peer certificate is the first certificate in the list. -ret = gnutls_x509_crt_import(cert, certs, GNUTLS_X509_FMT_DER); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_x509_crt_import: %s\n", - gnutls_strerror(ret)); - exit(1); -} -ret = gnutls_x509_crt_check_hostname(cert, host); -if (ret == 0 && !certificate_host_name_override(certs[0], host)) { - fprintf(stderr, "error: host name does not match certificate\n"); - exit(1); -} -gnutls_x509_crt_deinit(cert); - - In newer GNUTLS versions, certificate checking and host name validation can be combined using the gnutls_certificate_verify_peers3 function. - - An established TLS session can be used for sending and receiving data, as in Example 12.13, “Using a GNUTLS session”. - Example 12.13. Using a GNUTLS session -char buf[4096]; -snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host); -ret = gnutls_record_send(session, buf, strlen(buf)); -if (ret < 0) { - fprintf(stderr, "error: gnutls_record_send: %s\n", gnutls_strerror(ret)); - exit(1); -} -ret = gnutls_record_recv(session, buf, sizeof(buf)); -if (ret < 0) { - fprintf(stderr, "error: gnutls_record_recv: %s\n", gnutls_strerror(ret)); - exit(1); -} - - In order to shut down a connection in an orderly manner, you should call the gnutls_bye function. Finally, the session object can be deallocated using gnutls_deinit (see Example 12.14, “Using a GNUTLS session”). - Example 12.14. Using a GNUTLS session -// Initiate an orderly connection shutdown. -ret = gnutls_bye(session, GNUTLS_SHUT_RDWR); -if (ret < 0) { - fprintf(stderr, "error: gnutls_bye: %s\n", gnutls_strerror(ret)); - exit(1); -} -// Free the session object. -gnutls_deinit(session); -Implementing TLS Clients With OpenJDK12.2.3. Implementing TLS Clients With OpenJDK - The examples below use the following cryptographic-related classes: - -import java.security.NoSuchAlgorithmException; -import java.security.NoSuchProviderException; -import java.security.cert.CertificateEncodingException; -import java.security.cert.CertificateException; -import java.security.cert.X509Certificate; -import javax.net.ssl.SSLContext; -import javax.net.ssl.SSLParameters; -import javax.net.ssl.SSLSocket; -import javax.net.ssl.TrustManager; -import javax.net.ssl.X509TrustManager; - -import sun.security.util.HostnameChecker; - - If compatibility with OpenJDK 6 is required, it is necessary to use the internal class sun.security.util.HostnameChecker. (The public OpenJDK API does not provide any support for dissecting the subject distinguished name of an X.509 certificate, so a custom-written DER parser is needed—or we have to use an internal class, which we do below.) In OpenJDK 7, the setEndpointIdentificationAlgorithm method was added to the javax.net.ssl.SSLParameters class, providing an official way to implement host name checking. - - TLS connections are established using an SSLContext instance. With a properly configured OpenJDK installation, the SunJSSE provider uses the system-wide set of trusted root certificate authorities, so no further configuration is necessary. For backwards compatibility with OpenJDK 6, the TLSv1 provider has to be supported as a fall-back option. This is shown in Example 12.15, “Setting up an SSLContext for OpenJDK TLS clients”. - Example 12.15. Setting up an SSLContext for OpenJDK TLS clients -// Create the context. Specify the SunJSSE provider to avoid -// picking up third-party providers. Try the TLS 1.2 provider -// first, then fall back to TLS 1.0. -SSLContext ctx; -try { - ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); -} catch (NoSuchAlgorithmException e) { - try { - ctx = SSLContext.getInstance("TLSv1", "SunJSSE"); - } catch (NoSuchAlgorithmException e1) { - // The TLS 1.0 provider should always be available. - throw new AssertionError(e1); - } catch (NoSuchProviderException e1) { - throw new AssertionError(e1); - } -} catch (NoSuchProviderException e) { - // The SunJSSE provider should always be available. - throw new AssertionError(e); -} -ctx.init(null, null, null); - - In addition to the context, a TLS parameter object will be needed which adjusts the cipher suites and protocols (Example 12.16, “Setting up SSLParameters for TLS use with OpenJDK”). Like the context, these parameters can be reused for multiple TLS connections. - Example 12.16. Setting up SSLParameters for TLS use with OpenJDK -// Prepare TLS parameters. These have to applied to every TLS -// socket before the handshake is triggered. -SSLParameters params = ctx.getDefaultSSLParameters(); -// Do not send an SSL-2.0-compatible Client Hello. -ArrayList<String> protocols = new ArrayList<String>( - Arrays.asList(params.getProtocols())); -protocols.remove("SSLv2Hello"); -params.setProtocols(protocols.toArray(new String[protocols.size()])); -// Adjust the supported ciphers. -ArrayList<String> ciphers = new ArrayList<String>( - Arrays.asList(params.getCipherSuites())); -ciphers.retainAll(Arrays.asList( - "TLS_RSA_WITH_AES_128_CBC_SHA256", - "TLS_RSA_WITH_AES_256_CBC_SHA256", - "TLS_RSA_WITH_AES_256_CBC_SHA", - "TLS_RSA_WITH_AES_128_CBC_SHA", - "SSL_RSA_WITH_3DES_EDE_CBC_SHA", - "SSL_RSA_WITH_RC4_128_SHA1", - "SSL_RSA_WITH_RC4_128_MD5", - "TLS_EMPTY_RENEGOTIATION_INFO_SCSV")); -params.setCipherSuites(ciphers.toArray(new String[ciphers.size()])); - - As initialized above, the parameter object does not yet require host name checking. This has to be enabled separately, and this is only supported by OpenJDK 7 and later: - -params.setEndpointIdentificationAlgorithm("HTTPS"); - - All application protocols can use the "HTTPS" algorithm. (The algorithms have minor differences with regard to wildcard handling, which should not matter in practice.) - - Example 12.17, “Establishing a TLS connection with OpenJDK” shows how to establish the connection. Before the handshake is initialized, the protocol and cipher configuration has to be performed, by applying the parameter object params. (After this point, changes to params will not affect this TLS socket.) As mentioned initially, host name checking requires using an internal API on OpenJDK 6. - Example 12.17. Establishing a TLS connection with OpenJDK -// Create the socket and connect it at the TCP layer. -SSLSocket socket = (SSLSocket) ctx.getSocketFactory() - .createSocket(host, port); - -// Disable the Nagle algorithm. -socket.setTcpNoDelay(true); - -// Adjust ciphers and protocols. -socket.setSSLParameters(params); - -// Perform the handshake. -socket.startHandshake(); - -// Validate the host name. The match() method throws -// CertificateException on failure. -X509Certificate peer = (X509Certificate) - socket.getSession().getPeerCertificates()[0]; -// This is the only way to perform host name checking on OpenJDK 6. -HostnameChecker.getInstance(HostnameChecker.TYPE_TLS).match( - host, peer); - - Starting with OpenJDK 7, the last lines can be omitted, provided that host name verification has been enabled by calling the setEndpointIdentificationAlgorithm method on the params object (before it was applied to the socket). - - The TLS socket can be used as a regular socket, as shown in Example 12.18, “Using a TLS client socket in OpenJDK”. - Example 12.18. Using a TLS client socket in OpenJDK -socket.getOutputStream().write("GET / HTTP/1.0\r\n\r\n" - .getBytes(Charset.forName("UTF-8"))); -byte[] buffer = new byte[4096]; -int count = socket.getInputStream().read(buffer); -System.out.write(buffer, 0, count); -12.2.3.1. Overriding server certificate validation with OpenJDK 6 - Overriding certificate validation requires a custom trust manager. With OpenJDK 6, the trust manager lacks information about the TLS session, and to which server the connection is made. Certificate overrides have to be tied to specific servers (host names). Consequently, different TrustManager and SSLContext objects have to be used for different servers. - - In the trust manager shown in Example 12.19, “A customer trust manager for OpenJDK TLS clients”, the server certificate is identified by its SHA-256 hash. - Example 12.19. A customer trust manager for OpenJDK TLS clients -public class MyTrustManager implements X509TrustManager { - private final byte[] certHash; - - public MyTrustManager(byte[] certHash) throws Exception { - this.certHash = certHash; - } - - @Override - public void checkClientTrusted(X509Certificate[] chain, String authType) - throws CertificateException { - throw new UnsupportedOperationException(); - } - - @Override - public void checkServerTrusted(X509Certificate[] chain, - String authType) throws CertificateException { - byte[] digest = getCertificateDigest(chain[0]); - String digestHex = formatHex(digest); - - if (Arrays.equals(digest, certHash)) { - System.err.println("info: accepting certificate: " + digestHex); - } else { - throw new CertificateException("certificate rejected: " + - digestHex); - } - } - - @Override - public X509Certificate[] getAcceptedIssuers() { - return new X509Certificate[0]; - } -} - - This trust manager has to be passed to the init method of the SSLContext object, as show in Example 12.20, “Using a custom TLS trust manager with OpenJDK”. - Example 12.20. Using a custom TLS trust manager with OpenJDK -SSLContext ctx; -try { - ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); -} catch (NoSuchAlgorithmException e) { - try { - ctx = SSLContext.getInstance("TLSv1", "SunJSSE"); - } catch (NoSuchAlgorithmException e1) { - throw new AssertionError(e1); - } catch (NoSuchProviderException e1) { - throw new AssertionError(e1); - } -} catch (NoSuchProviderException e) { - throw new AssertionError(e); -} -MyTrustManager tm = new MyTrustManager(certHash); -ctx.init(null, new TrustManager[] {tm}, null); - - When certificate overrides are in place, host name verification should not be performed because there is no security requirement that the host name in the certificate matches the host name used to establish the connection (and it often will not). However, without host name verification, it is not possible to perform transparent fallback to certification validation using the system certificate store. - - The approach described above works with OpenJDK 6 and later versions. Starting with OpenJDK 7, it is possible to use a custom subclass of the javax.net.ssl.X509ExtendedTrustManager class. The OpenJDK TLS implementation will call the new methods, passing along TLS session information. This can be used to implement certificate overrides as a fallback (if certificate or host name verification fails), and a trust manager object can be used for multiple servers because the server address is available to the trust manager. - Implementing TLS Clients With NSS12.2.4. Implementing TLS Clients With NSS - The following code shows how to implement a simple TLS client using NSS. Note that the error handling needs replacing before production use. - - Using NSS needs several header files, as shown in Example 12.21, “Include files for NSS”. - Example 12.21. Include files for NSS -// NSPR include files -#include <prerror.h> -#include <prinit.h> - -// NSS include files -#include <nss.h> -#include <pk11pub.h> -#include <secmod.h> -#include <ssl.h> -#include <sslproto.h> - -// Private API, no other way to turn a POSIX file descriptor into an -// NSPR handle. -NSPR_API(PRFileDesc*) PR_ImportTCPSocket(int); - - Initializing the NSS library is a complex task (Example 12.22, “Initializing the NSS library”). It is not thread-safe. By default, the library is in export mode, and all strong ciphers are disabled. Therefore, after creating the NSSInitCContext object, we probe all the strong ciphers we want to use, and check if at least one of them is available. If not, we call NSS_SetDomesticPolicy to switch to unrestricted policy mode. This function replaces the existing global cipher suite policy, that is why we avoid calling it unless absolutely necessary. - - The simplest way to configured the trusted root certificates involves loading the libnssckbi.so NSS module with a call to the SECMOD_LoadUserModule function. The root certificates are compiled into this module. (The PEM module for NSS, libnsspem.so, offers a way to load trusted CA certificates from a file.) - Example 12.22. Initializing the NSS library -PR_Init(PR_USER_THREAD, PR_PRIORITY_NORMAL, 0); -NSSInitContext *const ctx = - NSS_InitContext("sql:/etc/pki/nssdb", "", "", "", NULL, - NSS_INIT_READONLY | NSS_INIT_PK11RELOAD); -if (ctx == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - -// Ciphers to enable. -static const PRUint16 good_ciphers[] = { - TLS_RSA_WITH_AES_128_CBC_SHA, - TLS_RSA_WITH_AES_256_CBC_SHA, - SSL_RSA_WITH_3DES_EDE_CBC_SHA, - SSL_NULL_WITH_NULL_NULL // sentinel -}; - -// Check if the current policy allows any strong ciphers. If it -// doesn't, switch to the "domestic" (unrestricted) policy. This is -// not thread-safe and has global impact. Consequently, we only do -// it if absolutely necessary. -int found_good_cipher = 0; -for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL; - ++p) { - PRInt32 policy; - if (SSL_CipherPolicyGet(*p, &policy) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: policy for cipher %u: error %d: %s\n", - (unsigned)*p, err, PR_ErrorToName(err)); - exit(1); - } - if (policy == SSL_ALLOWED) { - fprintf(stderr, "info: found cipher %x\n", (unsigned)*p); - found_good_cipher = 1; - break; - } -} -if (!found_good_cipher) { - if (NSS_SetDomesticPolicy() != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSS_SetDomesticPolicy: error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } -} - -// Initialize the trusted certificate store. -char module_name[] = "library=libnssckbi.so name=\"Root Certs\""; -SECMODModule *module = SECMOD_LoadUserModule(module_name, NULL, PR_FALSE); -if (module == NULL || !module->loaded) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - - Some of the effects of the initialization can be reverted with the following function calls: - -SECMOD_DestroyModule(module); -NSS_ShutdownContext(ctx); - - After NSS has been initialized, the TLS connection can be created (Example 12.23, “Creating a TLS connection with NSS”). The internal PR_ImportTCPSocket function is used to turn the POSIX file descriptor sockfd into an NSPR file descriptor. (This function is de-facto part of the NSS public ABI, so it will not go away.) Creating the TLS-capable file descriptor requires a model descriptor, which is configured with the desired set of protocols and ciphers. (The good_ciphers variable is part of Example 12.22, “Initializing the NSS library”.) We cannot resort to disabling ciphers not on a whitelist because by default, the AES cipher suites are disabled. The model descriptor is not needed anymore after TLS support has been activated for the existing connection descriptor. - - The call to SSL_BadCertHook can be omitted if no mechanism to override certificate verification is needed. The bad_certificate function must check both the host name specified for the connection and the certificate before granting the override. - - Triggering the actual handshake requires three function calls, SSL_ResetHandshake, SSL_SetURL, and SSL_ForceHandshake. (If SSL_ResetHandshake is omitted, SSL_ForceHandshake will succeed, but the data will not be encrypted.) During the handshake, the certificate is verified and matched against the host name. - Example 12.23. Creating a TLS connection with NSS -// Wrap the POSIX file descriptor. This is an internal NSPR -// function, but it is very unlikely to change. -PRFileDesc* nspr = PR_ImportTCPSocket(sockfd); -sockfd = -1; // Has been taken over by NSPR. - -// Add the SSL layer. -{ - PRFileDesc *model = PR_NewTCPSocket(); - PRFileDesc *newfd = SSL_ImportFD(NULL, model); - if (newfd == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - model = newfd; - newfd = NULL; - if (SSL_OptionSet(model, SSL_ENABLE_SSL2, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_ENABLE_SSL2 error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - if (SSL_OptionSet(model, SSL_V2_COMPATIBLE_HELLO, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_V2_COMPATIBLE_HELLO error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - if (SSL_OptionSet(model, SSL_ENABLE_DEFLATE, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_ENABLE_DEFLATE error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - - // Disable all ciphers (except RC4-based ciphers, for backwards - // compatibility). - const PRUint16 *const ciphers = SSL_GetImplementedCiphers(); - for (unsigned i = 0; i < SSL_GetNumImplementedCiphers(); i++) { - if (ciphers[i] != SSL_RSA_WITH_RC4_128_SHA - && ciphers[i] != SSL_RSA_WITH_RC4_128_MD5) { - if (SSL_CipherPrefSet(model, ciphers[i], PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: disable cipher %u: error %d: %s\n", - (unsigned)ciphers[i], err, PR_ErrorToName(err)); - exit(1); - } - } - } - - // Enable the strong ciphers. - for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL; - ++p) { - if (SSL_CipherPrefSet(model, *p, PR_TRUE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: enable cipher %u: error %d: %s\n", - (unsigned)*p, err, PR_ErrorToName(err)); - exit(1); - } - } - - // Allow overriding invalid certificate. - if (SSL_BadCertHook(model, bad_certificate, (char *)host) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_BadCertHook error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - - newfd = SSL_ImportFD(model, nspr); - if (newfd == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ImportFD error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - nspr = newfd; - PR_Close(model); -} - -// Perform the handshake. -if (SSL_ResetHandshake(nspr, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ResetHandshake error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -if (SSL_SetURL(nspr, host) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_SetURL error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -if (SSL_ForceHandshake(nspr) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ForceHandshake error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - - After the connection has been established, Example 12.24, “Using NSS for sending and receiving data” shows how to use the NSPR descriptor to communicate with the server. - Example 12.24. Using NSS for sending and receiving data -char buf[4096]; -snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host); -PRInt32 ret = PR_Write(nspr, buf, strlen(buf)); -if (ret < 0) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Write error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -ret = PR_Read(nspr, buf, sizeof(buf)); -if (ret < 0) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Read error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - - Example 12.25, “Closing NSS client connections” shows how to close the connection. - Example 12.25. Closing NSS client connections -// Send close_notify alert. -if (PR_Shutdown(nspr, PR_SHUTDOWN_BOTH) != PR_SUCCESS) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Read error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -// Closes the underlying POSIX file descriptor, too. -PR_Close(nspr); -Implementing TLS Clients With Python12.2.5. Implementing TLS Clients With Python - The Python distribution provides a TLS implementation in the ssl module (actually a wrapper around OpenSSL). The exported interface is somewhat restricted, so that the client code shown below does not fully implement the recommendations in Section 12.1.1, “OpenSSL Pitfalls”. - Important - Currently, most Python function which accept https:// URLs or otherwise implement HTTPS support do not perform certificate validation at all. (For example, this is true for the httplib and xmlrpclib modules.) If you use HTTPS, you should not use the built-in HTTP clients. The Curl class in the curl module, as provided by the python-pycurl package implements proper certificate validation. - - The ssl module currently does not perform host name checking on the server certificate. Example 12.26, “Implementing TLS host name checking Python (without wildcard support)” shows how to implement certificate matching, using the parsed certificate returned by getpeercert. - Example 12.26. Implementing TLS host name checking Python (without wildcard support) -def check_host_name(peercert, name): - """Simple certificate/host name checker. Returns True if the - certificate matches, False otherwise. Does not support - wildcards.""" - # Check that the peer has supplied a certificate. - # None/{} is not acceptable. - if not peercert: - return False - if peercert.has_key("subjectAltName"): - for typ, val in peercert["subjectAltName"]: - if typ == "DNS" and val == name: - return True - else: - # Only check the subject DN if there is no subject alternative - # name. - cn = None - for attr, val in peercert["subject"]: - # Use most-specific (last) commonName attribute. - if attr == "commonName": - cn = val - if cn is not None: - return cn == name - return False - - To turn a regular, connected TCP socket into a TLS-enabled socket, use the ssl.wrap_socket function. The function call in Example 12.27, “Establishing a TLS client connection with Python” provides additional arguments to override questionable defaults in OpenSSL and in the Python module. - • - ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5" selects relatively strong cipher suites with certificate-based authentication. (The call to check_host_name function provides additional protection against anonymous cipher suites.) - • - ssl_version=ssl.PROTOCOL_TLSv1 disables SSL 2.0 support. By default, the ssl module sends an SSL 2.0 client hello, which is rejected by some servers. Ideally, we would request OpenSSL to negotiated the most recent TLS version supported by the server and the client, but the Python module does not allow this. - • - cert_reqs=ssl.CERT_REQUIRED turns on certificate validation. - • - ca_certs='/etc/ssl/certs/ca-bundle.crt' initializes the certificate store with a set of trusted root CAs. Unfortunately, it is necessary to hard-code this path into applications because the default path in OpenSSL is not available through the Python ssl module. - - The ssl module (and OpenSSL) perform certificate validation, but the certificate must be compared manually against the host name, by calling the check_host_name defined above. - Example 12.27. Establishing a TLS client connection with Python -sock = ssl.wrap_socket(sock, - ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5", - ssl_version=ssl.PROTOCOL_TLSv1, - cert_reqs=ssl.CERT_REQUIRED, - ca_certs='/etc/ssl/certs/ca-bundle.crt') -# getpeercert() triggers the handshake as a side effect. -if not check_host_name(sock.getpeercert(), host): - raise IOError("peer certificate does not match host name") - - After the connection has been established, the TLS socket can be used like a regular socket: - -sock.write("GET / HTTP/1.1\r\nHost: " + host + "\r\n\r\n") -print sock.read() - - Closing the TLS socket is straightforward as well: - -sock.close() -Appendix A. Revision HistoryAppendix A. Revision History - Revision 0-1Thu Mar 7 2013Eric Christensen sparks@redhat.com - Initial publication. - - - - \ No newline at end of file diff --git a/defensive-coding/tmp/en-US/xml/Defensive_Coding.xml b/defensive-coding/tmp/en-US/xml/Defensive_Coding.xml deleted file mode 100644 index 27e4b13..0000000 --- a/defensive-coding/tmp/en-US/xml/Defensive_Coding.xml +++ /dev/null @@ -1,34 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - - Programming Languages - - - - - - - Specific Programming Tasks - - - - - - - - - - - Implementing Security Features - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Features/Authentication.xml b/defensive-coding/tmp/en-US/xml/Features/Authentication.xml deleted file mode 100644 index 32d294d..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/Authentication.xml +++ /dev/null @@ -1,105 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Authentication and Authorization -
- Authenticating servers - - When connecting to a server, a client has to make sure that it is actually talking to the server it expects. There are two different aspects, securing the network path, and making sure that the expected user runs the process on the target host. There are several ways to ensure that: - - - - - The server uses a TLS certificate which is valid according to the web browser public key infrastructure, and the client verifies the certificate and the host name. - - - - - - The server uses a TLS certificate which is expectedby the client (perhaps it is stored in a configuration file read by the client). In this case, no host name checking is required. - - - - - - On Linux, UNIX domain sockets (of the PF_UNIX protocol family, sometimes called PF_LOCAL) are restricted by file system permissions. If the server socket path is not world-writable, the server identity cannot be spoofed by local users. - - - - - - Port numbers less than 1024 (trusted ports) can only be used by root, so if a UDP or TCP server is running on the local host and it uses a trusted port, its identity is assured. (Not all operating systems enforce the trusted ports concept, and the network might not be trusted, so it is only useful on the local system.) - - - - - - - TLS () is the recommended way for securing connections over untrusted networks. - - - If the server port number is 1024 is higher, a local user can impersonate the process by binding to this socket, perhaps after crashing the real server by exploiting a denial-of-service vulnerability. - - -
- -
- Host-based authentication - - Host-based authentication uses access control lists (ACLs) to accept or deny requests from clients. Thsis authentication method comes in two flavors: IP-based (or, more generally, address-based) and name-based (with the name coming from DNS or /etc/hosts). IP-based ACLs often use prefix notation to extend access to entire subnets. Name-based ACLs sometimes use wildcards for adding groups of hosts (from entire DNS subtrees). (In the SSH context, host-based authentication means something completely different and is not covered in this section.) - - - Host-based authentication trust the network and may not offer sufficient granularity, so it has to be considered a weak form of authentication. On the other hand, IP-based authentication can be made extremely robust and can be applied very early in input processing, so it offers an opportunity for significantly reducing the number of potential attackers for many services. - - - The names returned by gethostbyaddr and getnameinfo functions cannot be trusted. (DNS PTR records can be set to arbitrary values, not just names belong to the address owner.) If these names are used for ACL matching, a forward lookup using gethostbyaddr or getaddrinfo has to be performed. The name is only valid if the original address is found among the results of the forward lookup (double-reverse lookup). - - - An empty ACL should deny all access (deny-by-default). If empty ACLs permits all access, configuring any access list must switch to deny-by-default for all unconfigured protocols, in both name-based and address-based variants. - - - Similarly, if an address or name is not matched by the list, it should be denied. However, many implementations behave differently, so the actual behavior must be documented properly. - - - IPv6 addresses can embed IPv4 addresses. There is no universally correct way to deal with this ambiguity. The behavior of the ACL implementation should be documented. - - -
- -
- UNIX domain socket authentication - - UNIX domain sockets (with address family AF_UNIX or AF_LOCAL) are restricted to the local host and offer a special authentication mechanism: credentials passing. - - - Nowadays, most systems support the SO_PEERCRED (Linux) or LOCAL_PEERCRED (FreeBSD) socket options, or the getpeereid (other BSDs, MacOS X). These interfaces provide direct access to the (effective) user ID on the other end of a domain socket connect, without cooperation from the other end. - - - Historically, credentials passing was implemented using ancillary data in the sendmsg and recvmsg functions. On some systems, only credentials data that the peer has explicitly sent can be received, and the kernel checks the data for correctness on the sending side. This means that both peers need to deal with ancillary data. Compared to that, the modern interfaces are easier to use. Both sets of interfaces vary considerably among UNIX-like systems, unfortunately. - - - If you want to authenticate based on supplementary groups, you should obtain the user ID using one of these methods, and look up the list of supplementary groups using getpwuid (or getpwuid_r) and getgrouplist. Using the PID and information from /proc/PID/status is prone to race conditions and insecure. - - -
- - - - - diff --git a/defensive-coding/tmp/en-US/xml/Features/TLS.xml b/defensive-coding/tmp/en-US/xml/Features/TLS.xml deleted file mode 100644 index e3d4a73..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/TLS.xml +++ /dev/null @@ -1,579 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Transport Layer Security - - Transport Layer Security (TLS, formerly Secure Sockets Layer/SSL) is the recommended way to to protect integrity and confidentiality while data is transferred over an untrusted network connection, and to identify the endpoint. - -
- Common Pitfalls - - TLS implementations are difficult to use, and most of them lack a clean API design. The following sections contain implementation-specific advice, and some generic pitfalls are mentioned below. - - - - - Most TLS implementations have questionable default TLS cipher suites. Most of them enable anonymous Diffie-Hellman key exchange (but we generally want servers to authenticate themselves). Many do not disable ciphers which are subject to brute-force attacks because of restricted key lengths. Some even disable all variants of AES in the default configuration. - - - When overriding the cipher suite defaults, it is recommended to disable all cipher suites which are not present on a whitelist, instead of simply enabling a list of cipher suites. This way, if an algorithm is disabled by default in the TLS implementation in a future security update, the application will not re-enable it. - - - - - - The name which is used in certificate validation must match the name provided by the user or configuration file. No host name canonicalization or IP address lookup must be performed. - - - - - - The TLS handshake has very poor performance if the TCP Nagle algorithm is active. You should switch on the TCP_NODELAY socket option (at least for the duration of the handshake), or use the Linux-specific TCP_CORK option. - - - Deactivating the TCP Nagle algorithm - - - - - - - - Implementing proper session resumption decreases handshake overhead considerably. This is important if the upper-layer protocol uses short-lived connections (like most application of HTTPS). - - - - - - Both client and server should work towards an orderly connection shutdown, that is send close_notify alerts and respond to them. This is especially important if the upper-layer protocol does not provide means to detect connection truncation (like some uses of HTTP). - - - - - - When implementing a server using event-driven programming, it is important to handle the TLS handshake properly because it includes multiple network round-trips which can block when an ordinary TCP accept would not. Otherwise, a client which fails to complete the TLS handshake for some reason will prevent the server from handling input from other clients. - - - - - - Unlike regular file descriptors, TLS connections cannot be passed between processes. Some TLS implementations add additional restrictions, and TLS connections generally cannot be used across fork function calls (see ). - - - - - -
- OpenSSL Pitfalls - - Some OpenSSL function use tri-state return values. Correct error checking is extremely important. Several functions return int values with the following meaning: - - - - - The value 1 indicates success (for example, a successful signature verification). - - - - - - The value 0 indicates semantic failure (for example, a signature verification which was unsuccessful because the signing certificate was self-signed). - - - - - - The value -1 indicates a low-level error in the system, such as failure to allocate memory using malloc. - - - - - - - Treating such tri-state return values as booleans can lead to security vulnerabilities. Note that some OpenSSL functions return boolean results or yet another set of status indicators. Each function needs to be checked individually. - - - Recovering precise error information is difficult. shows how to obtain a more precise error code after a function call on an SSL object has failed. However, there are still cases where no detailed error information is available (e.g., if SSL_shutdown fails due to a connection teardown by the other end). - - - Obtaining OpenSSL error codes - - - - - The OPENSSL_config function is documented to never fail. In reality, it can terminate the entire process if there is a failure accessing the configuration file. An error message is written to standard error, but which might not be visible if the function is called from a daemon process. - - - OpenSSL contains two separate ASN.1 DER decoders. One set of decoders operate on BIO handles (the input/output stream abstraction provided by OpenSSL); their decoder function names start with d2i_ and end in _fp or _bio (e.g., d2i_X509_fp or d2i_X509_bio). These decoders must not be used for parsing data from untrusted sources; instead, the variants without the _fp and _bio (e.g., d2i_X509) shall be used. The BIO variants have received considerably less testing and are not very robust. - - - For the same reason, the OpenSSL command line tools (such as openssl x509) are generally generally less robust than the actual library code. They use the BIO functions internally, and not the more robust variants. - - - The command line tools do not always indicate failure in the exit status of the openssl process. For instance, a verification failure in openssl verify result in an exit status of zero. - - - The OpenSSL server and client applications (openssl s_client and openssl s_server) are debugging tools and should never be used as generic clients. For instance, the s_client tool reacts in a surprisign way to lines starting with R and Q. - - - OpenSSL allows application code to access private key material over documented interfaces. This can significantly increase the part of the code base which has to undergo security certification. - - -
- -
- GNUTLS Pitfalls - - libgnutls.so.26 links to libpthread.so.0. Loading the threading library too late causes problems, so the main program should be linked with -lpthread as well. As a result, it can be difficult to use GNUTLS in a plugin which is loaded with the dlopen function. Another side effect is that applications which merely link against GNUTLS (even without actually using it) may incur a substantial overhead because other libraries automatically switch to thread-safe algorithms. - - - The gnutls_global_init function must be called before using any functionality provided by the library. This function is not thread-safe, so external locking is required, but it is not clear which lock should be used. Omitting the synchronization does not just lead to a memory leak, as it is suggested in the GNUTLS documentation, but to undefined behavior because there is no barrier that would enforce memory ordering. - - - The gnutls_global_deinit function does not actually deallocate all resources allocated by gnutls_global_init. It is currently not thread-safe. Therefore, it is best to avoid calling it altogether. - - - The X.509 implementation in GNUTLS is rather lenient. For example, it is possible to create and process X.509 version 1 certificates which carry extensions. These certificates are (correctly) rejected by other implementations. - - -
- -
- OpenJDK Pitfalls - - The Java cryptographic framework is highly modular. As a result, when you request an object implementing some cryptographic functionality, you cannot be completely sure that you end up with the well-tested, reviewed implementation in OpenJDK. - - - OpenJDK (in the source code as published by Oracle) and other implementations of the Java platform require that the system administrator has installed so-called unlimited strength jurisdiction policy files. Without this step, it is not possible to use the secure algorithms which offer sufficient cryptographic strength. Most downstream redistributors of OpenJDK remove this requirement. - - - Some versions of OpenJDK use /dev/random as the randomness source for nonces and other random data which is needed for TLS operation, but does not actually require physical randomness. As a result, TLS applications can block, waiting for more bits to become available in /dev/random. - - -
- -
- NSS Pitfalls - - NSS was not designed to be used by other libraries which can be linked into applications without modifying them. There is a lot of global state. There does not seem to be a way to perform required NSS initialization without race conditions. - - - If the NSPR descriptor is in an unexpected state, the SSL_ForceHandshake function can succeed, but no TLS handshake takes place, the peer is not authenticated, and subsequent data is exchanged in the clear. - - - NSS disables itself if it detects that the process underwent a fork after the library has been initialized. This behavior is required by the PKCS#11 API specification. - - -
- - -
- -
- TLS Clients - - Secure use of TLS in a client generally involves all of the following steps. (Individual instructions for specific TLS implementations follow in the next sections.) - - - - - The client must configure the TLS library to use a set of trusted root certificates. These certificates are provided by the system in /etc/ssl/certs or files derived from it. - - - - - - The client selects sufficiently strong cryptographic primitives and disables insecure ones (such as no-op encryption). Compression and SSL version 2 support must be disabled (including the SSLv2-compatible handshake). - - - - - - The client initiates the TLS connection. The Server Name Indication extension should be used if supported by the TLS implementation. Before switching to the encrypted connection state, the contents of all input and output buffers must be discarded. - - - - - - The client needs to validate the peer certificate provided by the server, that is, the client must check that there is a cryptographically protected chain from a trusted root certificate to the peer certificate. (Depending on the TLS implementation, a TLS handshake can succeed even if the certificate cannot be validated.) - - - - - - The client must check that the configured or user-provided server name matches the peer certificate provided by the server. - - - - - - - It is safe to provide users detailed diagnostics on certificate validation failures. Other causes of handshake failures and, generally speaking, any details on other errors reported by the TLS implementation (particularly exception tracebacks), must not be divulged in ways that make them accessible to potential attackers. Otherwise, it is possible to create decryption oracles. - - - - Depending on the application, revocation checking (against certificate revocations lists or via OCSP) and session resumption are important aspects of production-quality client. These aspects are not yet covered. - - - -
- Implementation TLS Clients With OpenSSL - - In the following code, the error handling is only exploratory. Proper error handling is required for production use, especially in libraries. - - - The OpenSSL library needs explicit initialization (see ). - - - OpenSSL library initialization - - - - - After that, a context object has to be created, which acts as a factory for connection objects (). We use an explicit cipher list so that we do not pick up any strange ciphers when OpenSSL is upgraded. The actual version requested in the client hello depends on additional restrictions in the OpenSSL library. If possible, you should follow the example code and use the default list of trusted root certificate authorities provided by the system because you would have to maintain your own set otherwise, which can be cumbersome. - - - OpenSSL client context creation - - - - - A single context object can be used to create multiple connection objects. It is safe to use the same SSL_CTX object for creating connections concurrently from multiple threads, provided that the SSL_CTX object is not modified (e.g., callbacks must not be changed). - - - After creating the TCP socket and disabling the Nagle algorithm (per ), the actual connection object needs to be created, as show in . If the handshake started by SSL_connect fails, the ssl_print_error_and_exit function from is called. - - - The certificate_validity_override function provides an opportunity to override the validity of the certificate in case the OpenSSL check fails. If such functionality is not required, the call can be removed, otherwise, the application developer has to implement it. - - - The host name passed to the functions SSL_set_tlsext_host_name and X509_check_host must be the name that was passed to getaddrinfo or a similar name resolution function. No host name canonicalization must be performed. The X509_check_host function used in the final step for host name matching is currently only implemented in OpenSSL 1.1, which is not released yet. In case host name matching fails, the function certificate_host_name_override is called. This function should check user-specific certificate store, to allow a connection even if the host name does not match the certificate. This function has to be provided by the application developer. Note that the override must be keyed by both the certificate and the host name. - - - Creating a client connection using OpenSSL - - - - - The connection object can be used for sending and receiving data, as in . It is also possible to create a BIO object and use the SSL object as the underlying transport, using BIO_set_ssl. - - - Using an OpenSSL connection to send and receive data - - - - - When it is time to close the connection, the SSL_shutdown function needs to be called twice for an orderly, synchronous connection termination (). This exchanges close_notify alerts with the server. The additional logic is required to deal with an unexpected close_notify from the server. Note that is necessary to explicitly close the underlying socket after the connection object has been freed. - - - Closing an OpenSSL connection in an orderly fashion - - - - - shows how to deallocate the context object when it is no longer needed because no further TLS connections will be established. - - - Closing an OpenSSL connection in an orderly fashion - - - - -
- -
- Implementation TLS Clients With GNUTLS - - This section describes how to implement a TLS client with full certificate validation (but without certificate revocation checking). Note that the error handling in is only exploratory and needs to be replaced before production use. - - - The GNUTLS library needs explicit initialization: - - - - Failing to do so can result in obscure failures in Base64 decoding. See for additional aspects of initialization. - - - Before setting up TLS connections, a credentials objects has to be allocated and initialized with the set of trusted root CAs (). - - - Initializing a GNUTLS credentials structure - - - - - After the last TLS connection has been closed, this credentials object should be freed: - - - - During its lifetime, the credentials object can be used to initialize TLS session objects from multiple threads, provided that it is not changed. - - - Once the TCP connection has been established, the Nagle algorithm should be disabled (see ). After that, the socket can be associated with a new GNUTLS session object. The previously allocated credentials object provides the set of root CAs. The NORMAL set of cipher suites and protocols provides a reasonable default. Then the TLS handshake must be initiated. This is shown in . - - - Establishing a TLS client connection using GNUTLS - - - - - After the handshake has been completed, the server certificate needs to be verified (). In the example, the user-defined certificate_validity_override function is called if the verification fails, so that a separate, user-specific trust store can be checked. This function call can be omitted if the functionality is not needed. - - - Verifying a server certificate using GNUTLS - - - - - In the next step (, the certificate must be matched against the host name (note the unusual return value from gnutls_x509_crt_check_hostname). Again, an override function certificate_host_name_override is called. Note that the override must be keyed to the certificate and the host name. The function call can be omitted if the override is not needed. - - - Matching the server host name and certificate in a GNUTLS client - - - - - In newer GNUTLS versions, certificate checking and host name validation can be combined using the gnutls_certificate_verify_peers3 function. - - - An established TLS session can be used for sending and receiving data, as in . - - - Using a GNUTLS session - - - - - In order to shut down a connection in an orderly manner, you should call the gnutls_bye function. Finally, the session object can be deallocated using gnutls_deinit (see ). - - - Using a GNUTLS session - - - - -
- -
- Implementing TLS Clients With OpenJDK - - The examples below use the following cryptographic-related classes: - - - - If compatibility with OpenJDK 6 is required, it is necessary to use the internal class sun.security.util.HostnameChecker. (The public OpenJDK API does not provide any support for dissecting the subject distinguished name of an X.509 certificate, so a custom-written DER parser is needed—or we have to use an internal class, which we do below.) In OpenJDK 7, the setEndpointIdentificationAlgorithm method was added to the javax.net.ssl.SSLParameters class, providing an official way to implement host name checking. - - - TLS connections are established using an SSLContext instance. With a properly configured OpenJDK installation, the SunJSSE provider uses the system-wide set of trusted root certificate authorities, so no further configuration is necessary. For backwards compatibility with OpenJDK 6, the TLSv1 provider has to be supported as a fall-back option. This is shown in . - - - Setting up an <literal>SSLContext</literal> for OpenJDK TLS clients - - - - - In addition to the context, a TLS parameter object will be needed which adjusts the cipher suites and protocols (). Like the context, these parameters can be reused for multiple TLS connections. - - - Setting up <literal>SSLParameters</literal> for TLS use with OpenJDK - - - - - As initialized above, the parameter object does not yet require host name checking. This has to be enabled separately, and this is only supported by OpenJDK 7 and later: - - - - All application protocols can use the "HTTPS" algorithm. (The algorithms have minor differences with regard to wildcard handling, which should not matter in practice.) - - - shows how to establish the connection. Before the handshake is initialized, the protocol and cipher configuration has to be performed, by applying the parameter object params. (After this point, changes to params will not affect this TLS socket.) As mentioned initially, host name checking requires using an internal API on OpenJDK 6. - - - Establishing a TLS connection with OpenJDK - - - - - Starting with OpenJDK 7, the last lines can be omitted, provided that host name verification has been enabled by calling the setEndpointIdentificationAlgorithm method on the params object (before it was applied to the socket). - - - The TLS socket can be used as a regular socket, as shown in . - - - Using a TLS client socket in OpenJDK - - - -
- Overriding server certificate validation with OpenJDK 6 - - Overriding certificate validation requires a custom trust manager. With OpenJDK 6, the trust manager lacks information about the TLS session, and to which server the connection is made. Certificate overrides have to be tied to specific servers (host names). Consequently, different TrustManager and SSLContext objects have to be used for different servers. - - - In the trust manager shown in , the server certificate is identified by its SHA-256 hash. - - - A customer trust manager for OpenJDK TLS clients - - - - - This trust manager has to be passed to the init method of the SSLContext object, as show in . - - - Using a custom TLS trust manager with OpenJDK - - - - - When certificate overrides are in place, host name verification should not be performed because there is no security requirement that the host name in the certificate matches the host name used to establish the connection (and it often will not). However, without host name verification, it is not possible to perform transparent fallback to certification validation using the system certificate store. - - - The approach described above works with OpenJDK 6 and later versions. Starting with OpenJDK 7, it is possible to use a custom subclass of the javax.net.ssl.X509ExtendedTrustManager class. The OpenJDK TLS implementation will call the new methods, passing along TLS session information. This can be used to implement certificate overrides as a fallback (if certificate or host name verification fails), and a trust manager object can be used for multiple servers because the server address is available to the trust manager. - - -
- - -
- -
- Implementing TLS Clients With NSS - - The following code shows how to implement a simple TLS client using NSS. Note that the error handling needs replacing before production use. - - - Using NSS needs several header files, as shown in . - - - Include files for NSS - - - - - Initializing the NSS library is a complex task (). It is not thread-safe. By default, the library is in export mode, and all strong ciphers are disabled. Therefore, after creating the NSSInitCContext object, we probe all the strong ciphers we want to use, and check if at least one of them is available. If not, we call NSS_SetDomesticPolicy to switch to unrestricted policy mode. This function replaces the existing global cipher suite policy, that is why we avoid calling it unless absolutely necessary. - - - The simplest way to configured the trusted root certificates involves loading the libnssckbi.so NSS module with a call to the SECMOD_LoadUserModule function. The root certificates are compiled into this module. (The PEM module for NSS, libnsspem.so, offers a way to load trusted CA certificates from a file.) - - - Initializing the NSS library - - - - - Some of the effects of the initialization can be reverted with the following function calls: - - - - After NSS has been initialized, the TLS connection can be created (). The internal PR_ImportTCPSocket function is used to turn the POSIX file descriptor sockfd into an NSPR file descriptor. (This function is de-facto part of the NSS public ABI, so it will not go away.) Creating the TLS-capable file descriptor requires a model descriptor, which is configured with the desired set of protocols and ciphers. (The good_ciphers variable is part of .) We cannot resort to disabling ciphers not on a whitelist because by default, the AES cipher suites are disabled. The model descriptor is not needed anymore after TLS support has been activated for the existing connection descriptor. - - - The call to SSL_BadCertHook can be omitted if no mechanism to override certificate verification is needed. The bad_certificate function must check both the host name specified for the connection and the certificate before granting the override. - - - Triggering the actual handshake requires three function calls, SSL_ResetHandshake, SSL_SetURL, and SSL_ForceHandshake. (If SSL_ResetHandshake is omitted, SSL_ForceHandshake will succeed, but the data will not be encrypted.) During the handshake, the certificate is verified and matched against the host name. - - - Creating a TLS connection with NSS - - - - - After the connection has been established, shows how to use the NSPR descriptor to communicate with the server. - - - Using NSS for sending and receiving data - - - - - shows how to close the connection. - - - Closing NSS client connections - - - - -
- -
- Implementing TLS Clients With Python - - The Python distribution provides a TLS implementation in the ssl module (actually a wrapper around OpenSSL). The exported interface is somewhat restricted, so that the client code shown below does not fully implement the recommendations in . - - - - Currently, most Python function which accept https:// URLs or otherwise implement HTTPS support do not perform certificate validation at all. (For example, this is true for the httplib and xmlrpclib modules.) If you use HTTPS, you should not use the built-in HTTP clients. The Curl class in the curl module, as provided by the python-pycurl package implements proper certificate validation. - - - - - The ssl module currently does not perform host name checking on the server certificate. shows how to implement certificate matching, using the parsed certificate returned by getpeercert. - - - Implementing TLS host name checking Python (without wildcard support) - - - - - To turn a regular, connected TCP socket into a TLS-enabled socket, use the ssl.wrap_socket function. The function call in provides additional arguments to override questionable defaults in OpenSSL and in the Python module. - - - - - ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5" selects relatively strong cipher suites with certificate-based authentication. (The call to check_host_name function provides additional protection against anonymous cipher suites.) - - - - - - ssl_version=ssl.PROTOCOL_TLSv1 disables SSL 2.0 support. By default, the ssl module sends an SSL 2.0 client hello, which is rejected by some servers. Ideally, we would request OpenSSL to negotiated the most recent TLS version supported by the server and the client, but the Python module does not allow this. - - - - - - cert_reqs=ssl.CERT_REQUIRED turns on certificate validation. - - - - - - ca_certs='/etc/ssl/certs/ca-bundle.crt' initializes the certificate store with a set of trusted root CAs. Unfortunately, it is necessary to hard-code this path into applications because the default path in OpenSSL is not available through the Python ssl module. - - - - - - - The ssl module (and OpenSSL) perform certificate validation, but the certificate must be compared manually against the host name, by calling the check_host_name defined above. - - - Establishing a TLS client connection with Python - - - - - After the connection has been established, the TLS socket can be used like a regular socket: - - - - Closing the TLS socket is straightforward as well: - - - -
- - -
- - - diff --git a/defensive-coding/tmp/en-US/xml/Features/schemas.xml b/defensive-coding/tmp/en-US/xml/Features/schemas.xml deleted file mode 100644 index 31581c3..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/schemas.xml +++ /dev/null @@ -1,6 +0,0 @@ - - -%BOOK_ENTITIES; -]> - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Connect.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Connect.xml deleted file mode 100644 index 9ff46c4..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Connect.xml +++ /dev/null @@ -1,53 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Create the session object. -gnutls_session_t session; -ret = gnutls_init(&session, GNUTLS_CLIENT); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_init: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Configure the cipher preferences. -const char *errptr = NULL; -ret = gnutls_priority_set_direct(session, "NORMAL", &errptr); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_priority_set_direct: %s\n" - "error: at: \"%s\"\n", gnutls_strerror(ret), errptr); - exit(1); -} - -// Install the trusted certificates. -ret = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, cred); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_credentials_set: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Associate the socket with the session object and set the server -// name. -gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t)(uintptr_t)sockfd); -ret = gnutls_server_name_set(session, GNUTLS_NAME_DNS, - host, strlen(host)); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_server_name_set: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Establish the session. -ret = gnutls_handshake(session); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_handshake: %s\n", - gnutls_strerror(ret)); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Credentials.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Credentials.xml deleted file mode 100644 index 1360058..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Credentials.xml +++ /dev/null @@ -1,32 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Load the trusted CA certificates. -gnutls_certificate_credentials_t cred = NULL; -int ret = gnutls_certificate_allocate_credentials (&cred); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_certificate_allocate_credentials: %s\n", - gnutls_strerror(ret)); - exit(1); -} -// gnutls_certificate_set_x509_system_trust needs GNUTLS version 3.0 -// or newer, so we hard-code the path to the certificate store -// instead. -static const char ca_bundle[] = "/etc/ssl/certs/ca-bundle.crt"; -ret = gnutls_certificate_set_x509_trust_file - (cred, ca_bundle, GNUTLS_X509_FMT_PEM); -if (ret == 0) { - fprintf(stderr, "error: no certificates found in: %s\n", ca_bundle); - exit(1); -} -if (ret < 0) { - fprintf(stderr, "error: gnutls_certificate_set_x509_trust_files(%s): %s\n", - ca_bundle, gnutls_strerror(ret)); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Match.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Match.xml deleted file mode 100644 index 5b6a42e..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Match.xml +++ /dev/null @@ -1,33 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Match the peer certificate against the host name. -// We can only obtain a set of DER-encoded certificates from the -// session object, so we have to re-parse the peer certificate into -// a certificate object. -gnutls_x509_crt_t cert; -ret = gnutls_x509_crt_init(&cert); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_x509_crt_init: %s\n", - gnutls_strerror(ret)); - exit(1); -} -// The peer certificate is the first certificate in the list. -ret = gnutls_x509_crt_import(cert, certs, GNUTLS_X509_FMT_DER); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_x509_crt_import: %s\n", - gnutls_strerror(ret)); - exit(1); -} -ret = gnutls_x509_crt_check_hostname(cert, host); -if (ret == 0 && !certificate_host_name_override(certs[0], host)) { - fprintf(stderr, "error: host name does not match certificate\n"); - exit(1); -} -gnutls_x509_crt_deinit(cert); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Verify.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Verify.xml deleted file mode 100644 index 11dbb65..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-GNUTLS-Verify.xml +++ /dev/null @@ -1,45 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Obtain the server certificate chain. The server certificate -// itself is stored in the first element of the array. -unsigned certslen = 0; -const gnutls_datum_t *const certs = - gnutls_certificate_get_peers(session, &certslen); -if (certs == NULL || certslen == 0) { - fprintf(stderr, "error: could not obtain peer certificate\n"); - exit(1); -} - -// Validate the certificate chain. -unsigned status = (unsigned)-1; -ret = gnutls_certificate_verify_peers2(session, &status); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_certificate_verify_peers2: %s\n", - gnutls_strerror(ret)); - exit(1); -} -if (status != 0 && !certificate_validity_override(certs[0])) { - gnutls_datum_t msg; -#if GNUTLS_VERSION_AT_LEAST_3_1_4 - int type = gnutls_certificate_type_get (session); - ret = gnutls_certificate_verification_status_print(status, type, &out, 0); -#else - ret = -1; -#endif - if (ret == 0) { - fprintf(stderr, "error: %s\n", msg.data); - gnutls_free(msg.data); - exit(1); - } else { - fprintf(stderr, "error: certificate validation failed with code 0x%x\n", - status); - exit(1); - } -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-NSS-Close.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-NSS-Close.xml deleted file mode 100644 index 46dd372..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-NSS-Close.xml +++ /dev/null @@ -1,18 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Send close_notify alert. -if (PR_Shutdown(nspr, PR_SHUTDOWN_BOTH) != PR_SUCCESS) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Read error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -// Closes the underlying POSIX file descriptor, too. -PR_Close(nspr); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-NSS-Connect.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-NSS-Connect.xml deleted file mode 100644 index 5fea050..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-NSS-Connect.xml +++ /dev/null @@ -1,109 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Wrap the POSIX file descriptor. This is an internal NSPR -// function, but it is very unlikely to change. -PRFileDesc* nspr = PR_ImportTCPSocket(sockfd); -sockfd = -1; // Has been taken over by NSPR. - -// Add the SSL layer. -{ - PRFileDesc *model = PR_NewTCPSocket(); - PRFileDesc *newfd = SSL_ImportFD(NULL, model); - if (newfd == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - model = newfd; - newfd = NULL; - if (SSL_OptionSet(model, SSL_ENABLE_SSL2, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_ENABLE_SSL2 error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - if (SSL_OptionSet(model, SSL_V2_COMPATIBLE_HELLO, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_V2_COMPATIBLE_HELLO error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - if (SSL_OptionSet(model, SSL_ENABLE_DEFLATE, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_ENABLE_DEFLATE error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - - // Disable all ciphers (except RC4-based ciphers, for backwards - // compatibility). - const PRUint16 *const ciphers = SSL_GetImplementedCiphers(); - for (unsigned i = 0; i < SSL_GetNumImplementedCiphers(); i++) { - if (ciphers[i] != SSL_RSA_WITH_RC4_128_SHA - && ciphers[i] != SSL_RSA_WITH_RC4_128_MD5) { - if (SSL_CipherPrefSet(model, ciphers[i], PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: disable cipher %u: error %d: %s\n", - (unsigned)ciphers[i], err, PR_ErrorToName(err)); - exit(1); - } - } - } - - // Enable the strong ciphers. - for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL; - ++p) { - if (SSL_CipherPrefSet(model, *p, PR_TRUE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: enable cipher %u: error %d: %s\n", - (unsigned)*p, err, PR_ErrorToName(err)); - exit(1); - } - } - - // Allow overriding invalid certificate. - if (SSL_BadCertHook(model, bad_certificate, (char *)host) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_BadCertHook error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - - newfd = SSL_ImportFD(model, nspr); - if (newfd == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ImportFD error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - nspr = newfd; - PR_Close(model); -} - -// Perform the handshake. -if (SSL_ResetHandshake(nspr, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ResetHandshake error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -if (SSL_SetURL(nspr, host) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_SetURL error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -if (SSL_ForceHandshake(nspr) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ForceHandshake error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Connect.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Connect.xml deleted file mode 100644 index 96024e6..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Connect.xml +++ /dev/null @@ -1,29 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Create the socket and connect it at the TCP layer. -SSLSocket socket = (SSLSocket) ctx.getSocketFactory() - .createSocket(host, port); - -// Disable the Nagle algorithm. -socket.setTcpNoDelay(true); - -// Adjust ciphers and protocols. -socket.setSSLParameters(params); - -// Perform the handshake. -socket.startHandshake(); - -// Validate the host name. The match() method throws -// CertificateException on failure. -X509Certificate peer = (X509Certificate) - socket.getSession().getPeerCertificates()[0]; -// This is the only way to perform host name checking on OpenJDK 6. -HostnameChecker.getInstance(HostnameChecker.TYPE_TLS).match( - host, peer); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Context.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Context.xml deleted file mode 100644 index 523b156..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Context.xml +++ /dev/null @@ -1,29 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Create the context. Specify the SunJSSE provider to avoid -// picking up third-party providers. Try the TLS 1.2 provider -// first, then fall back to TLS 1.0. -SSLContext ctx; -try { - ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); -} catch (NoSuchAlgorithmException e) { - try { - ctx = SSLContext.getInstance("TLSv1", "SunJSSE"); - } catch (NoSuchAlgorithmException e1) { - // The TLS 1.0 provider should always be available. - throw new AssertionError(e1); - } catch (NoSuchProviderException e1) { - throw new AssertionError(e1); - } -} catch (NoSuchProviderException e) { - // The SunJSSE provider should always be available. - throw new AssertionError(e); -} -ctx.init(null, null, null); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Context_For_Cert.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Context_For_Cert.xml deleted file mode 100644 index efc38b1..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Context_For_Cert.xml +++ /dev/null @@ -1,25 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -SSLContext ctx; -try { - ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); -} catch (NoSuchAlgorithmException e) { - try { - ctx = SSLContext.getInstance("TLSv1", "SunJSSE"); - } catch (NoSuchAlgorithmException e1) { - throw new AssertionError(e1); - } catch (NoSuchProviderException e1) { - throw new AssertionError(e1); - } -} catch (NoSuchProviderException e) { - throw new AssertionError(e); -} -MyTrustManager tm = new MyTrustManager(certHash); -ctx.init(null, new TrustManager[] {tm}, null); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Hostname.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Hostname.xml deleted file mode 100644 index a32d143..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Hostname.xml +++ /dev/null @@ -1,10 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -params.setEndpointIdentificationAlgorithm("HTTPS"); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Import.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Import.xml deleted file mode 100644 index 20bab18..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Import.xml +++ /dev/null @@ -1,21 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -import java.security.NoSuchAlgorithmException; -import java.security.NoSuchProviderException; -import java.security.cert.CertificateEncodingException; -import java.security.cert.CertificateException; -import java.security.cert.X509Certificate; -import javax.net.ssl.SSLContext; -import javax.net.ssl.SSLParameters; -import javax.net.ssl.SSLSocket; -import javax.net.ssl.TrustManager; -import javax.net.ssl.X509TrustManager; - -import sun.security.util.HostnameChecker; - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-MyTrustManager.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-MyTrustManager.xml deleted file mode 100644 index 539603c..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-MyTrustManager.xml +++ /dev/null @@ -1,41 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -public class MyTrustManager implements X509TrustManager { - private final byte[] certHash; - - public MyTrustManager(byte[] certHash) throws Exception { - this.certHash = certHash; - } - - @Override - public void checkClientTrusted(X509Certificate[] chain, String authType) - throws CertificateException { - throw new UnsupportedOperationException(); - } - - @Override - public void checkServerTrusted(X509Certificate[] chain, - String authType) throws CertificateException { - byte[] digest = getCertificateDigest(chain[0]); - String digestHex = formatHex(digest); - - if (Arrays.equals(digest, certHash)) { - System.err.println("info: accepting certificate: " + digestHex); - } else { - throw new CertificateException("certificate rejected: " + - digestHex); - } - } - - @Override - public X509Certificate[] getAcceptedIssuers() { - return new X509Certificate[0]; - } -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Use.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Use.xml deleted file mode 100644 index f31033d..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenJDK-Use.xml +++ /dev/null @@ -1,14 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -socket.getOutputStream().write("GET / HTTP/1.0\r\n\r\n" - .getBytes(Charset.forName("UTF-8"))); -byte[] buffer = new byte[4096]; -int count = socket.getInputStream().read(buffer); -System.out.write(buffer, 0, count); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-CTX.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-CTX.xml deleted file mode 100644 index 7a9ac3e..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-CTX.xml +++ /dev/null @@ -1,74 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Configure a client connection context. Send a hendshake for the -// highest supported TLS version, and disable compression. -const SSL_METHOD *const req_method = SSLv23_client_method(); -SSL_CTX *const ctx = SSL_CTX_new(req_method); -if (ctx == NULL) { - ERR_print_errors(bio_err); - exit(1); -} -SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_COMPRESSION); - -// Adjust the ciphers list based on a whitelist. First enable all -// ciphers of at least medium strength, to get the list which is -// compiled into OpenSSL. -if (SSL_CTX_set_cipher_list(ctx, "HIGH:MEDIUM") != 1) { - ERR_print_errors(bio_err); - exit(1); -} -{ - // Create a dummy SSL session to obtain the cipher list. - SSL *ssl = SSL_new(ctx); - if (ssl == NULL) { - ERR_print_errors(bio_err); - exit(1); - } - STACK_OF(SSL_CIPHER) *active_ciphers = SSL_get_ciphers(ssl); - if (active_ciphers == NULL) { - ERR_print_errors(bio_err); - exit(1); - } - // Whitelist of candidate ciphers. - static const char *const candidates[] = { - "AES128-GCM-SHA256", "AES128-SHA256", "AES256-SHA256", // strong ciphers - "AES128-SHA", "AES256-SHA", // strong ciphers, also in older versions - "RC4-SHA", "RC4-MD5", // backwards compatibility, supposed to be weak - "DES-CBC3-SHA", "DES-CBC3-MD5", // more backwards compatibility - NULL - }; - // Actually selected ciphers. - char ciphers[300]; - ciphers[0] = '\0'; - for (const char *const *c = candidates; *c; ++c) { - for (int i = 0; i < sk_SSL_CIPHER_num(active_ciphers); ++i) { - if (strcmp(SSL_CIPHER_get_name(sk_SSL_CIPHER_value(active_ciphers, i)), - *c) == 0) { - if (*ciphers) { - strcat(ciphers, ":"); - } - strcat(ciphers, *c); - break; - } - } - } - SSL_free(ssl); - // Apply final cipher list. - if (SSL_CTX_set_cipher_list(ctx, ciphers) != 1) { - ERR_print_errors(bio_err); - exit(1); - } -} - -// Load the set of trusted root certificates. -if (!SSL_CTX_set_default_verify_paths(ctx)) { - ERR_print_errors(bio_err); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Connect.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Connect.xml deleted file mode 100644 index 5f74292..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Connect.xml +++ /dev/null @@ -1,58 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Create the connection object. -SSL *ssl = SSL_new(ctx); -if (ssl == NULL) { - ERR_print_errors(bio_err); - exit(1); -} -SSL_set_fd(ssl, sockfd); - -// Enable the ServerNameIndication extension -if (!SSL_set_tlsext_host_name(ssl, host)) { - ERR_print_errors(bio_err); - exit(1); -} - -// Perform the TLS handshake with the server. -ret = SSL_connect(ssl); -if (ret != 1) { - // Error status can be 0 or negative. - ssl_print_error_and_exit(ssl, "SSL_connect", ret); -} - -// Obtain the server certificate. -X509 *peercert = SSL_get_peer_certificate(ssl); -if (peercert == NULL) { - fprintf(stderr, "peer certificate missing"); - exit(1); -} - -// Check the certificate verification result. Allow an explicit -// certificate validation override in case verification fails. -int verifystatus = SSL_get_verify_result(ssl); -if (verifystatus != X509_V_OK && !certificate_validity_override(peercert)) { - fprintf(stderr, "SSL_connect: verify result: %s\n", - X509_verify_cert_error_string(verifystatus)); - exit(1); -} - -// Check if the server certificate matches the host name used to -// establish the connection. -// FIXME: Currently needs OpenSSL 1.1. -if (X509_check_host(peercert, (const unsigned char *)host, strlen(host), - 0) != 1 - && !certificate_host_name_override(peercert, host)) { - fprintf(stderr, "SSL certificate does not match host name\n"); - exit(1); -} - -X509_free(peercert); - - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Connection-Use.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Connection-Use.xml deleted file mode 100644 index eb0ca16..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Connection-Use.xml +++ /dev/null @@ -1,18 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -const char *const req = "GET / HTTP/1.0\r\n\r\n"; -if (SSL_write(ssl, req, strlen(req)) < 0) { - ssl_print_error_and_exit(ssl, "SSL_write", ret); -} -char buf[4096]; -ret = SSL_read(ssl, buf, sizeof(buf)); -if (ret < 0) { - ssl_print_error_and_exit(ssl, "SSL_read", ret); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Init.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Init.xml deleted file mode 100644 index 9750b5c..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-OpenSSL-Init.xml +++ /dev/null @@ -1,16 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// The following call prints an error message and calls exit() if -// the OpenSSL configuration file is unreadable. -OPENSSL_config(NULL); -// Provide human-readable error messages. -SSL_load_error_strings(); -// Register ciphers. -SSL_library_init(); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-Python-Connect.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-Python-Connect.xml deleted file mode 100644 index c0e0395..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-Python-Connect.xml +++ /dev/null @@ -1,17 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -sock = ssl.wrap_socket(sock, - ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5", - ssl_version=ssl.PROTOCOL_TLSv1, - cert_reqs=ssl.CERT_REQUIRED, - ca_certs='/etc/ssl/certs/ca-bundle.crt') -# getpeercert() triggers the handshake as a side effect. -if not check_host_name(sock.getpeercert(), host): - raise IOError("peer certificate does not match host name") - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-Python-check_host_name.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-Python-check_host_name.xml deleted file mode 100644 index 0e22858..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Client-Python-check_host_name.xml +++ /dev/null @@ -1,32 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -def check_host_name(peercert, name): - """Simple certificate/host name checker. Returns True if the - certificate matches, False otherwise. Does not support - wildcards.""" - # Check that the peer has supplied a certificate. - # None/{} is not acceptable. - if not peercert: - return False - if peercert.has_key("subjectAltName"): - for typ, val in peercert["subjectAltName"]: - if typ == "DNS" and val == name: - return True - else: - # Only check the subject DN if there is no subject alternative - # name. - cn = None - for attr, val in peercert["subject"]: - # Use most-specific (last) commonName attribute. - if attr == "commonName": - cn = val - if cn is not None: - return cn == name - return False - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Credentials-Close.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Credentials-Close.xml deleted file mode 100644 index e0170b1..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Credentials-Close.xml +++ /dev/null @@ -1,10 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -gnutls_certificate_free_credentials(cred); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Disconnect.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Disconnect.xml deleted file mode 100644 index 9a18ea7..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Disconnect.xml +++ /dev/null @@ -1,17 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Initiate an orderly connection shutdown. -ret = gnutls_bye(session, GNUTLS_SHUT_RDWR); -if (ret < 0) { - fprintf(stderr, "error: gnutls_bye: %s\n", gnutls_strerror(ret)); - exit(1); -} -// Free the session object. -gnutls_deinit(session); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Init.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Init.xml deleted file mode 100644 index 2842eaf..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Init.xml +++ /dev/null @@ -1,10 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -gnutls_global_init(); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Use.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Use.xml deleted file mode 100644 index f67cc61..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-GNUTLS-Use.xml +++ /dev/null @@ -1,21 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -char buf[4096]; -snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host); -ret = gnutls_record_send(session, buf, strlen(buf)); -if (ret < 0) { - fprintf(stderr, "error: gnutls_record_send: %s\n", gnutls_strerror(ret)); - exit(1); -} -ret = gnutls_record_recv(session, buf, sizeof(buf)); -if (ret < 0) { - fprintf(stderr, "error: gnutls_record_recv: %s\n", gnutls_strerror(ret)); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Close.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Close.xml deleted file mode 100644 index 74bb39d..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Close.xml +++ /dev/null @@ -1,11 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -SECMOD_DestroyModule(module); -NSS_ShutdownContext(ctx); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Includes.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Includes.xml deleted file mode 100644 index ec955dd..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Includes.xml +++ /dev/null @@ -1,23 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// NSPR include files -#include <prerror.h> -#include <prinit.h> - -// NSS include files -#include <nss.h> -#include <pk11pub.h> -#include <secmod.h> -#include <ssl.h> -#include <sslproto.h> - -// Private API, no other way to turn a POSIX file descriptor into an -// NSPR handle. -NSPR_API(PRFileDesc*) PR_ImportTCPSocket(int); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Init.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Init.xml deleted file mode 100644 index f7ee2ef..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Init.xml +++ /dev/null @@ -1,66 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -PR_Init(PR_USER_THREAD, PR_PRIORITY_NORMAL, 0); -NSSInitContext *const ctx = - NSS_InitContext("sql:/etc/pki/nssdb", "", "", "", NULL, - NSS_INIT_READONLY | NSS_INIT_PK11RELOAD); -if (ctx == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - -// Ciphers to enable. -static const PRUint16 good_ciphers[] = { - TLS_RSA_WITH_AES_128_CBC_SHA, - TLS_RSA_WITH_AES_256_CBC_SHA, - SSL_RSA_WITH_3DES_EDE_CBC_SHA, - SSL_NULL_WITH_NULL_NULL // sentinel -}; - -// Check if the current policy allows any strong ciphers. If it -// doesn't, switch to the "domestic" (unrestricted) policy. This is -// not thread-safe and has global impact. Consequently, we only do -// it if absolutely necessary. -int found_good_cipher = 0; -for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL; - ++p) { - PRInt32 policy; - if (SSL_CipherPolicyGet(*p, &policy) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: policy for cipher %u: error %d: %s\n", - (unsigned)*p, err, PR_ErrorToName(err)); - exit(1); - } - if (policy == SSL_ALLOWED) { - fprintf(stderr, "info: found cipher %x\n", (unsigned)*p); - found_good_cipher = 1; - break; - } -} -if (!found_good_cipher) { - if (NSS_SetDomesticPolicy() != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSS_SetDomesticPolicy: error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } -} - -// Initialize the trusted certificate store. -char module_name[] = "library=libnssckbi.so name=\"Root Certs\""; -SECMODModule *module = SECMOD_LoadUserModule(module_name, NULL, PR_FALSE); -if (module == NULL || !module->loaded) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Use.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Use.xml deleted file mode 100644 index c3b3faf..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-NSS-Use.xml +++ /dev/null @@ -1,25 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -char buf[4096]; -snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host); -PRInt32 ret = PR_Write(nspr, buf, strlen(buf)); -if (ret < 0) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Write error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -ret = PR_Read(nspr, buf, sizeof(buf)); -if (ret < 0) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Read error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Nagle.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Nagle.xml deleted file mode 100644 index 2dbf3de..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Nagle.xml +++ /dev/null @@ -1,15 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -const int val = 1; -int ret = setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &val, sizeof(val)); -if (ret < 0) { - perror("setsockopt(TCP_NODELAY)"); - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenJDK-Parameters.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenJDK-Parameters.xml deleted file mode 100644 index 178978f..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenJDK-Parameters.xml +++ /dev/null @@ -1,30 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Prepare TLS parameters. These have to applied to every TLS -// socket before the handshake is triggered. -SSLParameters params = ctx.getDefaultSSLParameters(); -// Do not send an SSL-2.0-compatible Client Hello. -ArrayList<String> protocols = new ArrayList<String>( - Arrays.asList(params.getProtocols())); -protocols.remove("SSLv2Hello"); -params.setProtocols(protocols.toArray(new String[protocols.size()])); -// Adjust the supported ciphers. -ArrayList<String> ciphers = new ArrayList<String>( - Arrays.asList(params.getCipherSuites())); -ciphers.retainAll(Arrays.asList( - "TLS_RSA_WITH_AES_128_CBC_SHA256", - "TLS_RSA_WITH_AES_256_CBC_SHA256", - "TLS_RSA_WITH_AES_256_CBC_SHA", - "TLS_RSA_WITH_AES_128_CBC_SHA", - "SSL_RSA_WITH_3DES_EDE_CBC_SHA", - "SSL_RSA_WITH_RC4_128_SHA1", - "SSL_RSA_WITH_RC4_128_MD5", - "TLS_EMPTY_RENEGOTIATION_INFO_SCSV")); -params.setCipherSuites(ciphers.toArray(new String[ciphers.size()])); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Connection-Close.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Connection-Close.xml deleted file mode 100644 index c2c507e..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Connection-Close.xml +++ /dev/null @@ -1,33 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Send the close_notify alert. -ret = SSL_shutdown(ssl); -switch (ret) { -case 1: - // A close_notify alert has already been received. - break; -case 0: - // Wait for the close_notify alert from the peer. - ret = SSL_shutdown(ssl); - switch (ret) { - case 0: - fprintf(stderr, "info: second SSL_shutdown returned zero\n"); - break; - case 1: - break; - default: - ssl_print_error_and_exit(ssl, "SSL_shutdown 2", ret); - } - break; -default: - ssl_print_error_and_exit(ssl, "SSL_shutdown 1", ret); -} -SSL_free(ssl); -close(sockfd); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Context-Close.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Context-Close.xml deleted file mode 100644 index f74338d..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Context-Close.xml +++ /dev/null @@ -1,10 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -SSL_CTX_free(ctx); - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Errors.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Errors.xml deleted file mode 100644 index 68c3668..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-OpenSSL-Errors.xml +++ /dev/null @@ -1,34 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -static void __attribute__((noreturn)) -ssl_print_error_and_exit(SSL *ssl, const char *op, int ret) -{ - int subcode = SSL_get_error(ssl, ret); - switch (subcode) { - case SSL_ERROR_NONE: - fprintf(stderr, "error: %s: no error to report\n", op); - break; - case SSL_ERROR_WANT_READ: - case SSL_ERROR_WANT_WRITE: - case SSL_ERROR_WANT_X509_LOOKUP: - case SSL_ERROR_WANT_CONNECT: - case SSL_ERROR_WANT_ACCEPT: - fprintf(stderr, "error: %s: invalid blocking state %d\n", op, subcode); - break; - case SSL_ERROR_SSL: - fprintf(stderr, "error: %s: TLS layer problem\n", op); - case SSL_ERROR_SYSCALL: - fprintf(stderr, "error: %s: system call failed: %s\n", op, strerror(errno)); - break; - case SSL_ERROR_ZERO_RETURN: - fprintf(stderr, "error: %s: zero return\n", op); - } - exit(1); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Python-Close.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Python-Close.xml deleted file mode 100644 index 8820cef..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Python-Close.xml +++ /dev/null @@ -1,10 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -sock.close() - - diff --git a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Python-Use.xml b/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Python-Use.xml deleted file mode 100644 index cef5941..0000000 --- a/defensive-coding/tmp/en-US/xml/Features/snippets/TLS-Python-Use.xml +++ /dev/null @@ -1,11 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -sock.write("GET / HTTP/1.1\r\nHost: " + host + "\r\n\r\n") -print sock.read() - - diff --git a/defensive-coding/tmp/en-US/xml/Python/Language.xml b/defensive-coding/tmp/en-US/xml/Python/Language.xml deleted file mode 100644 index 3700f39..0000000 --- a/defensive-coding/tmp/en-US/xml/Python/Language.xml +++ /dev/null @@ -1,92 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - The Python Programming Language - - Python provides memory safety by default, so low-level security vulnerabilities are rare and typically needs fixing the Python interpreter or standard library itself. - - - Other sections with Python-specific advice include: - - - - - - - - - - - - - - - - - , in particular - - - - - - - - - - - -
- Dangerous standard library features - - Some areas of the standard library, notably the ctypes module, do not provide memory safety guarantees comparable to the rest of Python. If such functionality is used, the advice in should be followed. - - -
- -
- Run-time compilation and code generation - - The following Python functions and statements related to code execution should be avoided: - - - - - compile - - - - - eval - - - - - exec - - - - - execfile - - - - - - If you need to parse integers or floating point values, use the int and float functions instead of eval. Sandboxing untrusted Python code does not work reliably. - - -
- -
- Sandboxing - - The rexec Python module cannot safely sandbox untrusted code and should not be used. The standard CPython implementation is not suitable for sandboxing. - - -
- - - diff --git a/defensive-coding/tmp/en-US/xml/Python/schemas.xml b/defensive-coding/tmp/en-US/xml/Python/schemas.xml deleted file mode 100644 index 31581c3..0000000 --- a/defensive-coding/tmp/en-US/xml/Python/schemas.xml +++ /dev/null @@ -1,6 +0,0 @@ - - -%BOOK_ENTITIES; -]> - diff --git a/defensive-coding/tmp/en-US/xml/Revision_History.xml b/defensive-coding/tmp/en-US/xml/Revision_History.xml deleted file mode 100644 index 366debc..0000000 --- a/defensive-coding/tmp/en-US/xml/Revision_History.xml +++ /dev/null @@ -1,33 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Revision History - - - - 0-1 - Thu Mar 7 2013 - - Eric - Christensen - sparks@redhat.com - - - - - Initial publication. - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/Cryptography.xml b/defensive-coding/tmp/en-US/xml/Tasks/Cryptography.xml deleted file mode 100644 index ac00335..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/Cryptography.xml +++ /dev/null @@ -1,158 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Cryptography -
- Primitives - - Chosing from the following cryptographic primitives is recommended: - - - - - RSA with 2048 bit keys and OAEP - - - - - AES-128 in CBC mode - - - - - SHA-256 - - - - - HMAC-SHA-256 - - - - - HMAC-SHA-1 - - - - - - Other cryptographic algorithms can be used if they are required for interoperability with existing software: - - - - - RSA with key sizes larger than 1024 and legacy padding - - - - - AES-192 - - - - - AES-256 - - - - - 3DES (triple DES, with two or three 56 bit keys) - - - - - RC4 (but very, very strongly discouraged) - - - - - SHA-1 - - - - - HMAC-MD5 - - - - - - Important - - These primitives are difficult to use in a secure way. Custom implementation of security protocols should be avoided. For protecting confidentiality and integrity of network transmissions, TLS should be used (). - - - - -
- -
- Randomness - - The following facilities can be used to generate unpredictable and non-repeating values. When these functions are used without special safeguards, each individual rnadom value should be at least 12 bytes long. - - - - - PK11_GenerateRandom in the NSS library (usable for high data rates) - - - - - - RAND_bytes in the OpenSSL library (usable for high data rates) - - - - - - gnutls_rnd in GNUTLS, with GNUTLS_RND_RANDOM as the first argument (usable for high data rates) - - - - - - java.security.SecureRandom in Java (usable for high data rates) - - - - - - os.urandom in Python - - - - - - Reading from the /dev/urandom character device - - - - - - - All these functions should be non-blocking, and they should not wait until physical randomness becomes available. (Some cryptography providers for Java can cause java.security.SecureRandom to block, however.) Those functions which do not obtain all bits directly from /dev/urandom are suitable for high data rates because they do not deplete the system-wide entropy pool. - - - Difficult to use API - - Both RAND_bytes and PK11_GenerateRandom have three-state return values (with conflicting meanings). Careful error checking is required. Please review the documentation when using these functions. - - - - - Other sources of randomness should be considered predictable. - - - Generating randomness for cryptographic keys in long-term use may need different steps and is best left to cryptographic libraries. - - -
- - - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/Descriptors.xml b/defensive-coding/tmp/en-US/xml/Tasks/Descriptors.xml deleted file mode 100644 index fe273df..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/Descriptors.xml +++ /dev/null @@ -1,154 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - File Descriptor Management - - File descriptors underlie all input/output mechanisms offered by the system. They are used to implementation the FILE *-based functions found in <stdio.h>, and all the file and network communication facilities provided by the Python and Java environments are eventually implemented in them. - - - File descriptors are small, non-negative integers in userspace, and are backed on the kernel side with complicated data structures which can sometimes grow very large. - -
- Closing descriptors - - If a descriptor is no longer used by a program and is not closed explicitly, its number cannot be reused (which is problematic in itself, see ), and the kernel resources are not freed. Therefore, it is important to close all descriptors at the earlierst point in time possible, but not earlier. - -
- Error handling during descriptor close - - The close system call is always successful in the sense that the passed file descriptor is never valid after the function has been called. However, close still can return an error, for example if there was a file system failure. But this error is not very useful because the absence of an error does not mean that all caches have been emptied and previous writes have been made durable. Programs which need such guarantees must open files with O_SYNC or use fsync or fdatasync, and may also have to fsync the directory containing the file. - - -
- -
- Closing descriptors and race conditions - - Unlike process IDs, which are recycle only gradually, the kernel always allocates the lowest unused file descriptor when a new descriptor is created. This means that in a multi-threaded program which constantly opens and closes file descriptors, descriptors are reused very quickly. Unless descriptor closing and other operations on the same file descriptor are synchronized (typically, using a mutex), there will be race coniditons and I/O operations will be applied to the wrong file descriptor. - - - Sometimes, it is necessary to close a file descriptor concurrently, while another thread might be about to use it in a system call. In order to support this, a program needs to create a single special file descriptor, one on which all I/O operations fail. One way to achieve this is to use socketpair, close one of the descriptors, and call shutdown(fd, SHUTRDWR) on the other. - - - When a descriptor is closed concurrently, the program does not call close on the descriptor. Instead it program uses dup2 to replace the descriptor to be closed with the dummy descriptor created earlier. This way, the kernel will not reuse the descriptor, but it will carry out all other steps associated with calling a descriptor (for instance, if the descriptor refers to a stream socket, the peer will be notified). - - - This is just a sketch, and many details are missing. Additional data structures are needed to determine when it is safe to really close the descriptor, and proper locking is required for that. - - -
- -
- Lingering state after close - - By default, closing a stream socket returns immediately, and the kernel will try to send the data in the background. This means that it is impossible to implement accurate accounting of network-related resource utilization from userspace. - - - The SO_LINGER socket option alters the behavior of close, so that it will return only after the lingering data has been processed, either by sending it to the peer successfully, or by discarding it after the configured timeout. However, there is no interface which could perform this operation in the background, so a separate userspace thread is needed for each close call, causing scalability issues. - - - Currently, there is no application-level countermeasure which applies universally. Mitigation is possible with iptables (the connlimit match type in particular) and specialized filtering devices for denial-of-service network traffic. - - - These problems are not related to the TIME_WAIT state commonly seen in netstat output. The kernel automatically expires such sockets if necessary. - - -
- - -
- -
- Preventing file descriptor leaks to child processes - - Child processes created with fork share the initial set of file descriptors with their parent process. By default, file descriptors are also preserved if a new process image is created with execve (or any of the other functions such as system or posix_spawn). - - - Usually, this behavior is not desirable. There are two ways to turn it off, that is, to prevent new process images from inheriting the file descriptors in the parent process: - - - - - Set the close-on-exec flag on all newly created file descriptors. Traditionally, this flag is controlled by the FD_CLOEXEC flag, using F_GETFD and F_SETFD operations of the fcntl function. - - - However, in a multi-threaded process, there is a race condition: a subprocess could have been created between the time the descriptor was created and the FD_CLOEXEC was set. Therefore, many system calls which create descriptors (such as open and openat) now accept the O_CLOEXEC flag (SOCK_CLOEXEC for socket and socketpair), which cause the FD_CLOEXEC flag to be set for the file descriptor in an atomic fashion. In addition, a few new systems calls were introduced, such as pipe2 and dup3. - - - The downside of this approach is that every descriptor needs to receive special treatment at the time of creation, otherwise it is not completely effective. - - - - - - After calling fork, but before creating a new process image with execve, all file descriptors which the child process will not need are closed. - - - Traditionally, this was implemented as a loop over file descriptors ranging from 3 to 255 and later 1023. But this is only an approximatio because it is possible to create file descriptors outside this range easily (see ). Another approach reads /proc/self/fd and closes the unexpected descriptors listed there, but this approach is much slower. - - - - - - - At present, environments which care about file descriptor leakage implement the second approach. OpenJDK 6 and 7 are among them. - - -
- -
- Dealing with the <function>select</function> limit - - By default, a user is allowed to open only 1024 files in a single process, but the system administrator can easily change this limit (which is necessary for busy network servers). However, there is another restriction which is more difficult to overcome. - - - The select function only supports a maximum of FD_SETSIZE file descriptors (that is, the maximum permitted value for a file descriptor is FD_SETSIZE - 1, usually 1023.) If a process opens many files, descriptors may exceed such limits. It is impossible to query such descriptors using select. - - - If a library which creates many file descriptors is used in the same process as a library which uses select, at least one of them needs to be changed. Calls to select can be replaced with calls to poll or another event handling mechanism. - - - Alternatively, the library with high descriptor usage can relocate descriptors above the FD_SETSIZE limit using the following procedure. - - - - - Create the file descriptor fd as usual, preferably with the O_CLOEXEC flag. - - - - - - Before doing anything else with the descriptor fd, invoke: - - - - int newfd = fcntl(fd, F_DUPFD_CLOEXEC, (long)FD_SETSIZE); - - - - - - Check that newfd result is non-negative, otherwise close fd and report an error, and return. - - - - - - Close fd and continue to use newfd. - - - - - - - The new descriptor has been allocated above the FD_SETSIZE. Even though this algorithm is racy in the sense that the FD_SETSIZE first descriptors could fill up, a very high degree of physical parallelism is required before this becomes a problem. - - -
- - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/File_System.xml b/defensive-coding/tmp/en-US/xml/Tasks/File_System.xml deleted file mode 100644 index 644c570..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/File_System.xml +++ /dev/null @@ -1,196 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - File system manipulation - - In this chapter, we discuss general file system manipulation, with a focus on access files and directories to which an other, potentially untrusted user has write access. - - - Temporary files are covered in their own chapter, . - -
- Working with files and directories owned by other users - - Sometimes, it is necessary to operate on files and directories owned by other (potentially untrusted) users. For example, a system administrator could remove the home directory of a user, or a package manager could update a file in a directory which is owned by an application-specific user. This differs from accessing the file system as a specific user; see . - - - Accessing files across trust boundaries faces several challenges, particularly if an entire directory tree is being traversed: - - - - - Another user might add file names to a writable directory at any time. This can interfere with file creation and the order of names returned by readdir. - - - - - - Merely opening and closing a file can have side effects. For instance, an automounter can be triggered, or a tape device rewound. Opening a file on a local file system can block indefinitely, due to mandatory file locking, unless the O_NONBLOCK flag is specified. - - - - - - Hard links and symbolic links can redirect the effect of file system operations in unexpected ways. The O_NOFOLLOW and AT_SYMLINK_NOFOLLOW variants of system calls only affected final path name component. - - - - - - The structure of a directory tree can change. For example, the parent directory of what used to be a subdirectory within the directory tree being processed could suddenly point outside that directory tree. - - - - - - - Files should always be created with the O_CREAT and O_EXCL flags, so that creating the file will fail if it already exists. This guards against the unexpected appearance of file names, either due to creation of a new file, or hard-linking of an existing file. In multi-threaded programs, rather than manipulating the umask, create the files with mode 000 if possible, and adjust it afterwards with fchmod. - - - To avoid issues related to symbolic links and directory tree restructuring, the “at” variants of system calls have to be used (that is, functions like openat, fchownat, fchmodat, and unlinkat, together with O_NOFOLLOW or AT_SYMLINK_NOFOLLOW). Path names passed to these functions must have just a single component (that is, without a slash). When descending, the descriptors of parent directories must be kept open. The missing opendirat function can be emulated with openat (with an O_DIRECTORY flag, to avoid opening special files with side effects), followed by fdopendir. - - - If the “at” functions are not available, it is possible to emulate them by changing the current directory. (Obviously, this only works if the process is not multi-threaded.) fchdir has to be used to change the current directory, and the descriptors of the parent directories have to be kept open, just as with the “at”-based approach. chdir("...") is unsafe because it might ascend outside the intended directory tree. - - - This “at” function emulation is currently required when manipulating extended attributes. In this case, the lsetxattr function can be used, with a relative path name consisting of a single component. This also applies to SELinux contexts and the lsetfilecon function. - - - Currently, it is not possible to avoid opening special files and changes to files with hard links if the directory containing them is owned by an untrusted user. (Device nodes can be hard-linked, just as regular files.) fchmodat and fchownat affect files whose link count is greater than one. But opening the files, checking that the link count is one with fstat, and using fchmod and fchown on the file descriptor may have unwanted side effects, due to item 2 above. When creating directories, it is therefore important to change the ownership and permissions only after it has been fully created. Until that point, file names are stable, and no files with unexpected hard links can be introduced. - - - Similarly, when just reading a directory owned by an untrusted user, it is currently impossible to reliably avoid opening special files. - - - There is no workaround against the instability of the file list returned by readdir. Concurrent modification of the directory can result in a list of files being returned which never actually existed on disk. - - - Hard links and symbolic links can be safely deleted using unlinkat without further checks because deletion only affects the name within the directory tree being processed. - - -
- -
- Accessing the file system as a different user - - This section deals with access to the file system as a specific user. This is different from accessing files and directories owned by a different, potentially untrusted user; see . - - - One approach is to spawn a child process which runs under the target user and group IDs (both effective and real IDs). Note that this child process can block indefinitely, even when processing regular files only. For example, a special FUSE file system could cause the process to hang in uninterruptible sleep inside a stat system call. - - - An existing process could change its user and group ID using setfsuid and setfsgid. (These functions are preferred over seteuid and setegid because they do not allow the impersonated user to send signals to the process.) These functions are not thread safe. In multi-threaded processes, these operations need to be performed in a single-threaded child process. Unexpected blocking may occur as well. - - - It is not recommended to try to reimplement the kernel permission checks in user space because the required checks are complex. It is also very difficult to avoid race conditions during path name resolution. - - -
- -
- File system limits - - For historical reasons, there are preprocessor constants such as PATH_MAX, NAME_MAX. However, on most systems, the length of canonical path names (absolute path names with all symbolic links resolved, as returned by realpath or canonicalize_file_name) can exceed PATH_MAX bytes, and individual file name components can be longer than NAME_MAX. This is also true of the _PC_PATH_MAX and _PC_NAME_MAX values returned by pathconf, and the f_namemax member of struct statvfs. Therefore, these constants should not be used. This is also reason why the readdir_r should never be used (instead, use readdir). - - - You should not write code in a way that assumes that there is an upper limit on the number of subdirectories of a directory, the number of regular files in a directory, or the link count of an inode. - - -
- -
- File system features - - Not all file systems support all features. This makes it very difficult to write general-purpose tools for copying files. For example, a copy operation intending to preserve file permissions will generally fail when copying to a FAT file system. - - - - - Some file systems are case-insensitive. Most should be case-preserving, though. - - - - - - Name length limits vary greatly, from eight to thousands of bytes. Path length limits differ as well. Most systems impose an upper bound on path names passed to the kernel, but using relative path names, it is possible to create and access files whose absolute path name is essentially of unbounded length. - - - - - - Some file systems do not store names as fairly unrestricted byte sequences, as it has been traditionally the case on GNU systems. This means that some byte sequences (outside the POSIX safe character set) are not valid names. Conversely, names of existing files may not be representable as byte sequences, and the files are thus inaccessible on GNU systems. Some file systems perform Unicode canonicalization on file names. These file systems preserve case, but reading the name of a just-created file using readdir might still result in a different byte sequence. - - - - - - Permissions and owners are not universally supported (and SUID/SGID bits may not be available). For example, FAT file systems assign ownership based on a mount option, and generally mark all files as executable. Any attempt to change permissions would result in an error. - - - - - - Non-regular files (device nodes, FIFOs) are not generally available. - - - - - - Only on some file systems, files can have holes, that is, not all of their contents is backed by disk storage. - - - - - - ioctl support (even fairly generic functionality such as FIEMAP for discovering physical file layout and holes) is file-system-specific. - - - - - - Not all file systems support extended attributes, ACLs and SELinux metadata. Size and naming restriction on extended attributes vary. - - - - - - Hard links may not be supported at all (FAT) or only within the same directory (AFS). Symbolic links may not be available, either. Reflinks (hard links with copy-on-write semantics) are still very rare. Recent systems restrict creation of hard links to users which own the target file or have read/write access to it, but older systems do not. - - - - - - Renaming (or moving) files using rename can fail (even when stat indicates that the source and target directories are located on the same file system). This system call should work if the old and new paths are located in the same directory, though. - - - - - - Locking semantics vary among file systems. This affects advisory and mandatory locks. For example, some network file systems do not allow deleting files which are opened by any process. - - - - - - Resolution of time stamps varies from two seconds to nanoseconds. Not all time stamps are available on all file systems. File creation time (birth time) is not exposed over the stat/fstat interface, even if stored by the file system. - - - - - - -
- -
- Checking free space - - The statvfs and fstatvfs functions allow programs to examine the number of available blocks and inodes, through the members f_bfree, f_bavail, f_ffree, and f_favail of struct statvfs. Some file systems return fictional values in the f_ffree and f_favail fields, so the only reliable way to discover if the file system still has space for a file is to try to create it. The f_bfree field should be reasonably accurate, though. - - -
- - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/Library_Design.xml b/defensive-coding/tmp/en-US/xml/Tasks/Library_Design.xml deleted file mode 100644 index 94e8ffd..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/Library_Design.xml +++ /dev/null @@ -1,136 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Library Design - - Throught this section, the term client code refers to applications and other libraries using the library. - -
- State management - - - -
- Global state - - Global state should be avoided. - - - If this is impossible, the global state must be protected with a lock. For C/C++, you can use the pthread_mutex_lock and pthread_mutex_unlock functions without linking against -lpthread because the system provides stubs for non-threaded processes. - - - For compatibility with fork, these locks should be acquired and released in helpers registered with pthread_atfork. This function is not available without -lpthread, so you need to use dlsym or a weak symbol to obtain its address. - - - If you need fork protection for other reasons, you should store the process ID and compare it to the value returned by getpid each time you access the global state. (getpid is not implemented as a system call and is fast.) If the value changes, you know that you have to re-create the state object. (This needs to be combined with locking, of course.) - - -
- -
- Handles - - Library state should be kept behind a curtain. Client code should receive only a handle. In C, the handle can be a pointer to an incomplete struct. In C++, the handle can be a pointer to an abstract base class, or it can be hidden using the pointer-to-implementation idiom. - - - The library should provide functions for creating and destroying handles. (In C++, it is possible to use virtual destructors for the latter.) Consistency between creation and destruction of handles is strongly recommended: If the client code created a handle, it is the responsibility of the client code to destroy it. (This is not always possible or convenient, so sometimes, a transfer of ownership has to happen.) - - - Using handles ensures that it is possible to change the way the library represents state in a way that is transparent to client code. This is important to facilitate security updates and many other code changes. - - - It is not always necessary to protect state behind a handle with a lock. This depends on the level of thread safety the library provides. - - -
- - -
- -
- Object orientation - - Classes should be either designed as base classes, or it should be impossible to use them as base classes (like final classes in Java). Classes which are not designed for inheritance and are used as base classes nevertheless create potential maintenance hazards because it is difficult to predict how client code will react when calls to virtual methods are added, reordered or removed. - - - Virtual member functions can be used as callbacks. See for some of the challenges involved. - - -
- -
- Callbacks - - Higher-order code is difficult to analyze for humans and computers alike, so it should be avoided. Often, an iterator-based interface (a library function which is called repeatedly by client code and returns a stream of events) leads to a better design which is easier to document and use. - - - If callbacks are unavoidable, some guidelines for them follow. - - - In modern C++ code, std::function objects should be used for callbacks. - - - In older C++ code and in C code, all callbacks must have an additional closure parameter of type void *, the value of which can be specified by client code. If possible, the value of the closure parameter should be provided by client code at the same time a specific callback is registered (or specified as a function argument). If a single closure parameter is shared by multiple callbacks, flexibility is greatly reduced, and conflicts between different pieces of client code using the same library object could be unresolvable. In some cases, it makes sense to provide a de-registration callback which can be used to destroy the closure parameter when the callback is no longer used. - - - Callbacks can throw exceptions or call longjmp. If possible, all library objects should remain in a valid state. (All further operations on them can fail, but it should be possible to deallocate them without causing resource leaks.) - - - The presence of callbacks raises the question if functions provided by the library are reentrant. Unless a library was designed for such use, bad things will happen if a callback function uses functions in the same library (particularly if they are invoked on the same objects and manipulate the same state). When the callback is invoked, the library can be in an inconsistent state. Reentrant functions are more difficult to write than thread-safe functions (by definition, simple locking would immediately lead to deadlocks). It is also difficult to decide what to do when destruction of an object which is currently processing a callback is requested. - - -
- -
- Process attributes - - Several attributes are global and affect all code in the process, not just the library that manipulates them. - - - - - environment variables (see ) - - - - - umask - - - - - user IDs, group IDs and capabilities - - - - - current working directory - - - - - signal handlers, signal masks and signal delivery - - - - - file locks (especially fcntl locks behave in surprising ways, not just in a multi-threaded environment) - - - - - - Library code should avoid manipulating these global process attributes. It should not rely on environment variables, umask, the current working directory and signal masks because these attributes can be inherted from an untrusted source. - - - In addition, there are obvious process-wide aspects such as the virtual memory layout, the set of open files and dynamic shared objects, but with the exception of shared objects, these can be manipulated in a relatively isolated way. - - -
- - - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/Locking.xml b/defensive-coding/tmp/en-US/xml/Tasks/Locking.xml deleted file mode 100644 index 270f4b2..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/Locking.xml +++ /dev/null @@ -1,8 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/Processes.xml b/defensive-coding/tmp/en-US/xml/Tasks/Processes.xml deleted file mode 100644 index 9de6cc5..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/Processes.xml +++ /dev/null @@ -1,322 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Processes -
- Safe process creation - - This section describes how to create new child processes in a safe manner. In addition to the concerns addressed below, there is the possibility of file descriptor leaks, see . - -
- Obtaining the program path and the command line template - - The name and path to the program being invoked should be hard-coded or controlled by a static configuration file stored at a fixed location (at an file system absolute path). The same applies to the template for generating the command line. - - - The configured program name should be an absolute path. If it is a relative path, the contents of the PATH must be obtained in s secure manner (see ). If the PATH variable is not set or untrusted, the safe default /bin:/usr/bin must be used. - - - If too much flexibility is provided here, it may allow invocation of arbitrary programs without proper authorization. - - -
- -
- Bypassing the shell - - Child processes should be created without involving the system shell. - - - For C/C++, system should not be used. The posix_spawn function can be used instead, or a combination fork and execve. (In some cases, it may be preferable to use vfork or the Linux-specific clone system call instead of fork.) - - - In Python, the subprocess module bypasses the shell by default (when the shell keyword argument is not set to true). os.system should not be used. - - - The Java class java.lang.ProcessBuilder can be used to create subprocesses without interference from the system shell. - - - Portability notice - - On Windows, there is no argument vector, only a single argument string. Each application is responsible for parsing this string into an argument vector. There is considerable variance among the quoting style recognized by applications. Some of them expand shell wildcards, others do not. Extensive application-specific testing is required to make this secure. - - - - - Note that some common applications (notably ssh) unconditionally introduce the use of a shell, even if invoked directly without a shell. It is difficult to use these applications in a secure manner. In this case, untrusted data should be supplied by other means. For example, standard input could be used, instead of the command line. - - -
- -
- Specifying the process environment - - Child processes should be created with a minimal set of environment variables. This is absolutely essential if there is a trust transition involved, either when the parent process was created, or during the creation of the child process. - - - In C/C++, the environment should be constructed as an array of strings and passed as the envp argument to posix_spawn or execve. The functions setenv, unsetenv and putenv should not be used. They are not thread-safe and suffer from memory leaks. - - - Python programs need to specify a dict for the the env argument of the subprocess.Popen constructor. The Java class java.lang.ProcessBuilder provides a environment() method, which returns a map that can be manipulated. - - - The following list provides guidelines for selecting the set of environment variables passed to the child process. - - - - - PATH should be initialized to /bin:/usr/bin. - - - - - - USER and HOME can be inhereted from the parent process environment, or they can be initialized from the pwent structure for the user. - - - - - - The DISPLAY and XAUTHORITY variables should be passed to the subprocess if it is an X program. Note that this will typically not work across trust boundaries because XAUTHORITY refers to a file with 0600 permissions. - - - - - - The location-related environment variables LANG, LANGUAGE, LC_ADDRESS, LC_ALL, LC_COLLATE, LC_CTYPE, LC_IDENTIFICATION, LC_MEASUREMENT, LC_MESSAGES, LC_MONETARY, LC_NAME, LC_NUMERIC, LC_PAPER, LC_TELEPHONE and LC_TIME can be passed to the subprocess if present. - - - - - - The called process may need application-specific environment variables, for example for passing passwords. (See .) - - - - - - All other environment variables should be dropped. Names for new environment variables should not be accepted from untrusted sources. - - - - - - -
- -
- Robust argument list processing - - When invoking a program, it is sometimes necessary to include data from untrusted sources. Such data should be check against embedded NUL characters because the system APIs will sliently truncate argument strings at the first NUL character. - - - The following recommendations assume that the program being invoked uses GNU-style option processing using getopt_long. This convention is widely used, but it is just that, and individual programs might interpret a command line in a different way. - - - If the untrusted data has to go into an option, use the --option-name=VALUE syntax, placing the option and its value into the same command line argument. This avoids any potential confusion if the data starts with -. - - - For positional arguments, terminate the option list with a single marker after the last option, and include the data at the right position. The marker terminates option processing, and the data will not be treated as an option even if it starts with a dash. - - -
- -
- Passing secrets to subprocesses - - The command line (the name of the program and its argument) of a running process is traditionally available to all local users. The called program can overwrite this information, but only after it has run for a bit of time, during which the information may have been read by other processes. However, on Linux, the process environment is restricted to the user who runs the process. Therefore, if you need a convenient way to pass a password to a child process, use an environment variable, and not a command line argument. (See .) - - - Portability notice - - On some UNIX-like systems (notably Solaris), environment variables can be read by any system user, just like command lines. - - - - - If the environment-based approach cannot be used due to portability concerns, the data can be passed on standard input. Some programs (notably gpg) use special file descriptors whose numbers are specified on the command line. Temporary files are an option as well, but they might give digital forensics access to sensitive data (such as passphrases) because it is difficult to safely delete them in all cases. - - -
- - -
- -
- Handling child process termination - - When child processes terminate, the parent process is signalled. A stub of the terminated processes (a zombie, shown as <defunct> by ps) is kept around until the status information is collected (reaped) by the parent process. Over the years, several interfaces for this have been invented: - - - - - The parent process calls wait, waitpid, waitid, wait3 or wait4, without specifying a process ID. This will deliver any matching process ID. This approach is typically used from within event loops. - - - - - - The parent process calls waitpid, waitid, or wait4, with a specific process ID. Only data for the specific process ID is returned. This is typically used in code which spawns a single subprocess in a synchronous manner. - - - - - - The parent process installs a handler for the SIGCHLD signal, using sigaction, and specifies to the SA_NOCLDWAIT flag. This approach could be used by event loops as well. - - - - - - - None of these approaches can be used to wait for child process terminated in a completely thread-safe manner. The parent process might execute an event loop in another thread, which could pick up the termination signal. This means that libraries typically cannot make free use of child processes (for example, to run problematic code with reduced privileges in a separate address space). - - - At the moment, the parent process should explicitly wait for termination of the child process using waitpid or waitpid, and hope that the status is not collected by an event loop first. - - -
- -
- <literal>SUID</literal>/<literal>SGID</literal> processes - - Programs can be marked in the file system to indicate to the kernel that a trust transition should happen if the program is run. The SUID file permission bit indicates that an executable should run with the effective user ID equal to the owner of the executable file. Similarly, with the SGID bit, the effective group ID is set to the group of the executable file. - - - Linux supports fscaps, which can grant additional capabilities to a process in a finer-grained manner. Additional mechanisms can be provided by loadable security modules. - - - When such a trust transition has happened, the process runs in a potentially hostile environment. Additional care is necessary not to rely on any untrusted information. These concerns also apply to libraries which can be linked into such processes. - -
- Accessing environment variables - - The following steps are required so that a program does not accidentally pick up untrusted data from environment variables. - - - - - Compile your C/C++ sources with -D_GNU_SOURCE. The Autoconf macro AC_GNU_SOURCE ensures this. - - - - - Check for the presence of the secure_getenv and __secure_getenv function. The Autoconf directive AC_CHECK_FUNCS([__secure_getenv secure_getenv]) performs these checks. - - - - - Arrange for a proper definition of the secure_getenv function. See . - - - - - Use secure_getenv instead of getenv to obtain the value of critical environment variables. secure_getenv will pretend the variable has not bee set if the process environment is not trusted. - - - - - - Critical environment variables are debugging flags, configuration file locations, plug-in and log file locations, and anything else that might be used to bypass security restrictions or cause a privileged process to behave in an unexpected way. - - - Either the secure_getenv function or the __secure_getenv is available from GNU libc. - - - Obtaining a definition for <function>secure_getenv</function> - - - -#include <stdlib.h> - -#ifndef HAVE_SECURE_GETENV -# ifdef HAVE__SECURE_GETENV -# define secure_getenv __secure_getenv -# else -# error neither secure_getenv nor __secure_getenv are available -# endif -#endif - - - - - -
- - -
- -
- Daemons - - Background processes providing system services (daemons) need to decouple themselves from the controlling terminal and the parent process environment: - - - - - Fork. - - - - - - In the child process, call setsid. The parent process can simply exit (using _exit, to avoid running clean-up actions twice). - - - - - - In the child process, fork again. Processing continues in the child process. Again, the parent process should just exit. - - - - - - Replace the descriptors 0, 1, 2 with a descriptor for /dev/null. Logging should be redirected to syslog. - - - - - - - Older instructions for creating daemon processes recommended a call to umask(0). This is risky because it often leads to world-writable files and directories, resulting in security vulnerabilities such as arbitrary process termination by untrusted local users, or log file truncation. If the umask needs setting, a restrictive value such as 027 or 077 is recommended. - - - Other aspects of the process environment may have to changed as well (environment variables, signal handler disposition). - - - It is increasingly common that server processes do not run as background processes, but as regular foreground process under a supervising master process (such as systemd). Server processes should offer a command line option which disables forking and replacement of the standard output and standard error streams. Such an option is also useful for debugging. - - -
- -
- Semantics of command line arguments - - After process creation and option processing, it is up to the child process to interpret the arguments. Arguments can be file names, host names, or URLs, and many other things. URLs can refer to the local network, some server on the Internet, or to the local file system. Some applications even accept arbitrary code in arguments (for example, python with the option). - - - Similar concerns apply to environment variables, the contents of the current directory and its subdirectories. - - - Consequently, careful analysis is required if it is safe to pass untrusted data to another program. - - -
- -
- <function>fork</function> as a primitive for parallelism - - A call to fork which is not immediately followed by a call to execve (perhaps after rearranging and closing file descriptors) is typically unsafe, especially from a library which does not control the state of the entire process. Such use of fork should be replaced with proper child processes or threads. - - -
- - - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/Serialization.xml b/defensive-coding/tmp/en-US/xml/Tasks/Serialization.xml deleted file mode 100644 index a6f9db2..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/Serialization.xml +++ /dev/null @@ -1,292 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Serialization and Deserialization - - Protocol decoders and file format parsers are often the most-exposed part of an application because they are exposed with little or no user interaction and before any authentication and security checks are made. They are also difficult to write robustly in languages which are not memory-safe. - -
- Recommendations for manually written decoders - - For C and C++, the advice in applies. In addition, avoid non-character pointers directly into input buffers. Pointer misalignment causes crashes on some architectures. - - - When reading variable-sized objects, do not allocate large amounts of data solely based on the value of a size field. If possible, grow the data structure as more data is read from the source, and stop when no data is available. This helps to avoid denial-of-service attacks where little amounts of input data results in enormous memory allocations during decoding. Alternatively, you can impose reasonable bounds on memory allocations, but some protocols do not permit this. - - -
- -
- Protocol design - - Binary formats with explicit length fields are more difficult to parse robustly than those where the length of dynamically-sized elements is derived from sentinel values. A protocol which does not use length fields and can be written in printable ASCII characters simplifies testing and debugging. However, binary protocols with length fields may be more efficient to parse. - - -
- -
- Library support for deserialization - - For some languages, generic libraries are available which allow to serialize and deserialize user-defined objects. The deserialization part comes in one of two flavors, depending on the library. The first kind uses type information in the data stream to control which objects are instantiated. The second kind uses type definitions supplied by the programmer. The first one allows arbitrary object instantiation, the second one generally does not. - - - The following serialization frameworks are in the first category, are known to be unsafe, and must not be used for untrusted data: - - - - - Python's pickle and cPickle modules - - - - - Perl's Storable package - - - - - Java serialization (java.io.ObjectInputStream) - - - - - PHP serialization (unserialize) - - - - - Most implementations of YAML - - - - - - When using a type-directed deserialization format where the types of the deserialized objects are specified by the programmer, make sure that the objects which can be instantiated cannot perform any destructive actions in their destructors, even when the data members have been manipulated. - - - JSON decoders do not suffer from this problem. But you must not use the eval function to parse JSON objects in Javascript; even with the regular expression filter from RFC 4627, there are still information leaks remaining. - - -
- -
- XML serialization - - - -
- External references - - XML documents can contain external references. They can occur in various places. - - - - - In the DTD declaration in the header of an XML document: - - - -<!DOCTYPE html PUBLIC - "-//W3C//DTD XHTML 1.0 Transitional//EN" - "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> - - - - - - In a namespace declaration: - - - -<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> - - - - - - In an entity defintion: - - - -<!ENTITY sys SYSTEM "http://www.example.com/ent.xml"> -<!ENTITY pub PUBLIC "-//Example//Public Entity//EN" - "http://www.example.com/pub-ent.xml"> - - - - - - In a notation: - - - -<!NOTATION not SYSTEM "../not.xml"> - - - - - - - Originally, these external references were intended as unique identifiers, but by many XML implementations, they are used for locating the data for the referenced element. This causes unwanted network traffic, and may disclose file system contents or otherwise unreachable network resources, so this functionality should be disabled. - - - Depending on the XML library, external referenced might be processed not just when parsing XML, but also when generating it. - - -
- -
- Entity expansion - - When external DTD processing is disabled, an internal DTD subset can still contain entity definitions. Entity declarations can reference other entities. Some XML libraries expand entities automatically, and this processing cannot be switched off in some places (such as attribute values or content models). Without limits on the entity nesting level, this expansion results in data which can grow exponentially in length with size of the input. (If there is a limit on the nesting level, the growth is still polynomial, unless further limits are imposed.) - - - Consequently, the processing internal DTD subsets should be disabled if possible, and only trusted DTDs should be processed. If a particular XML application does not permit such restrictions, then application-specific limits are called for. - - -
- -
- XInclude processing - - XInclude processing can reference file and network resources and include them into the document, much like external entity references. When parsing untrusted XML documents, XInclude processing should be truned off. - - - XInclude processing is also fairly complex and may pull in support for the XPointer and XPath specifications, considerably increasing the amount of code required for XML processing. - - -
- -
- Algorithmic complexity of XML validation - - DTD-based XML validation uses regular expressions for content models. The XML specification requires that content models are deterministic, which means that efficient validation is possible. However, some implementations do not enforce determinism, and require exponential (or just polynomial) amount of space or time for validating some DTD/document combinations. - - - XML schemas and RELAX NG (via the xsd: prefix) directly support textual regular expressions which are not required to be deterministic. - - -
- -
- Using Expat for XML parsing - - By default, Expat does not try to resolve external IDs, so no steps are required to block them. However, internal entity declarations are processed. Installing a callback which stops parsing as soon as such entities are encountered disables them, see . Expat does not perform any validation, so there are no problems related to that. - - - Disabling XML entity processing with Expat - - - - - This handler must be installed when the XML_Parser object is created (). - - - Creating an Expat XML parser - - - - - It is also possible to reject internal DTD subsets altogeher, using a suitable XML_StartDoctypeDeclHandler handler installed with XML_SetDoctypeDeclHandler. - - -
- -
- Using OpenJDK for XML parsing and validation - - OpenJDK contains facilities for DOM-based, SAX-based, and StAX-based document parsing. Documents can be validated against DTDs or XML schemas. - - - The approach taken to deal with entity expansion differs from the general recommendation in . We enable the the feature flag javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, which enforces heuristic restrictions on the number of entity expansions. Note that this flag alone does not prevent resolution of external references (system IDs or public IDs), so it is slightly misnamed. - - - In the following sections, we use helper classes to prevent external ID resolution. - - - Helper class to prevent DTD external entity resolution in OpenJDK - - - - - Helper class to prevent schema resolution in OpenJDK - - - - - shows the imports used by the examples. - - - Java imports for OpenJDK XML parsing - - - -
- DOM-based XML parsing and DTD validation in OpenJDK - - This approach produces a org.w3c.dom.Document object from an input stream. use the data from the java.io.InputStream instance in the inputStream variable. - - - DOM-based XML parsing in OpenJDK - - - - - External entity references are prohibited using the NoEntityResolver class in . Because external DTD references are prohibited, DTD validation (if enabled) will only happen against the internal DTD subset embedded in the XML document. - - - To validate the document against an external DTD, use a javax.xml.transform.Transformer class to add the DTD reference to the document, and an entity resolver which whitelists this external reference. - - -
- -
- XML Schema validation in OpenJDK - - shows how to validate a document against an XML Schema, using a SAX-based approach. The XML data is read from an java.io.InputStream in the inputStream variable. - - - SAX-based validation against an XML schema in OpenJDK - - - - - The NoResourceResolver class is defined in . - - - If you need to validate a document against an XML schema, use the code in to create the document, but do not enable validation at this point. Then use to perform the schema-based validation on the org.w3c.dom.Document instance document. - - - Validation of a DOM document against an XML schema in OpenJDK - - - - -
- - -
- - -
- -
- Protocol Encoders - - For protocol encoders, you should write bytes to a buffer which grows as needed, using an exponential sizing policy. Explicit lengths can be patched in later, once they are known. Allocating the required number of bytes upfront typically requires separate code to compute the final size, which must be kept in sync with the actual encoding step, or vulnerabilities may result. In multi-threaded code, parts of the object being deserialized might change, so that the computed size is out of date. - - - You should avoid copying data directly from a received packet during encoding, disregarding the format. Propagating malformed data could enable attacks on other recipients of that data. - - - When using C or C++ and copying whole data structures directly into the output, make sure that you do not leak information in padding bytes between fields or at the end of the struct. - - -
- - - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/Temporary_Files.xml b/defensive-coding/tmp/en-US/xml/Tasks/Temporary_Files.xml deleted file mode 100644 index 3b0160d..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/Temporary_Files.xml +++ /dev/null @@ -1,172 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Temporary files - - In this chapter, we describe how to create temporary files and directories, how to remove them, and how to work with programs which do not create files in ways that a safe with a shared directory for temporary files. General file system manipulation is treated in a separate chapter, . - - - Secure creation of temporary files has four different aspects. - - - - - The location of the directory for temporary files must be obtained in a secure manner (that is, untrusted environment variables must be ignored, see ). - - - - - - A new file must be created. Reusing an existing file must be avoided (the /tmp race condition). This is tricky because traditionally, system-wide temporary directories shared by all users are used. - - - - - - The file must be created in a way that makes it impossible for other users to open it. - - - - - - The descriptor for the temporary file should not leak to subprocesses. - - - - - - - All functions mentioned below will take care of these aspects. - - - Traditionally, temporary files are often used to reduce memory usage of programs. More and more systems use RAM-based file systems such as tmpfs for storing temporary files, to increase performance and decrease wear on Flash storage. As a result, spooling data to temporary files does not result in any memory savings, and the related complexity can be avoided if the data is kept in process memory. - -
- Obtaining the location of temporary directory - - Some functions below need the location of a directory which stores temporary files. For C/C++ programs, use the following steps to obtain that directory: - - - - - Use secure_getenv to obtain the value of the TMPDIR environment variable. If it is set, convert the path to a fully-resolved absolute path, using realpath(path, NULL). Check if the new path refers to a directory and is writeable. In this case, use it as the temporary directory. - - - - - - Fall back to /tmp. - - - - - - - In Python, you can use the tempfile.tempdir variable. - - - Java does not support SUID/SGID programs, so you can use the java.lang.System.getenv(String) method to obtain the value of the TMPDIR environment variable, and follow the two steps described above. (Java's default directory selection does not honor TMPDIR.) - - -
- -
- Named temporary files - - The mkostemp function creates a named temporary file. You should specify the O_CLOEXEC flag to avoid file descriptor leaks to subprocesses. (Applications which do not use multiple threads can also use mkstemp, but libraries should use mkostemp.) For determining the directory part of the file name pattern, see . - - - The file is not removed automatically. It is not safe to rename or delete the file before processing, or transform the name in any way (for example, by adding a file extension). If you need multiple temporary files, call mkostemp multiple times. Do not create additional file names derived from the name provided by a previous mkostemp call. However, it is safe to close the descriptor returned by mkostemp and reopen the file using the generated name. - - - The Python class tempfile.NamedTemporaryFile provides similar functionality, except that the file is deleted automatically by default. Note that you may have to use the file attribute to obtain the actual file object because some programming interfaces cannot deal with file-like objects. The C function mkostemp is also available as tempfile.mkstemp. - - - In Java, you can use the java.io.File.createTempFile(String, String, File) function, using the temporary file location determined according to . Do not use java.io.File.deleteOnExit() to delete temporary files, and do not register a shutdown hook for each temporary file you create. In both cases, the deletion hint cannot be removed from the system if you delete the temporary file prior to termination of the VM, causing a memory leak. - - -
- -
- Temporary files without names - - The tmpfile function creates a temporary file and immediately deletes it, while keeping the file open. As a result, the file lacks a name and its space is deallocated as soon as the file descriptor is closed (including the implicit close when the process terminates). This avoids cluttering the temporary directory with orphaned files. - - - Alternatively, if the maximum size of the temporary file is known beforehand, the fmemopen function can be used to create a FILE * object which is backed by memory. - - - In Python, unnamed temporary files are provided by the tempfile.TemporaryFile class, and the tempfile.SpooledTemporaryFile class provides a way to avoid creation of small temporary files. - - - Java does not support unnamed temporary files. - - -
- -
- Temporary directories - - The mkdtemp function can be used to create a temporary directory. (For determining the directory part of the file name pattern, see .) The directory is not automatically removed. In Python, this function is available as tempfile.mkdtemp. In Java 7, temporary directories can be created using the java.nio.file.Files.createTempDirectory(Path, String, FileAttribute...) function. - - - When creating files in the temporary directory, use automatically generated names, e.g., derived from a sequential counter. Files with externally provided names could be picked up in unexpected contexts, and crafted names could actually point outside of the tempoary directory (due to directory traversal). - - - Removing a directory tree in a completely safe manner is complicated. Unless there are overriding performance concerns, the rm program should be used, with the and options. - - -
- -
- Compensating for unsafe file creation - - There are two ways to make a function or program which excepts a file name safe for use with temporary files. See , for details on subprocess creation. - - - - - Create a temporary directory and place the file there. If possible, run the program in a subprocess which uses the temporary directory as its current directory, with a restricted environment. Use generated names for all files in that temporary directory. (See .) - - - - - - Create the temporary file and pass the generated file name to the function or program. This only works if the function or program can cope with a zero-length existing file. It is safe only under additional assumptions: - - - - - The function or program must not create additional files whose name is derived from the specified file name or are otherwise predictable. - - - - - - The function or program must not delete the file before processing it. - - - - - - It must not access any existing files in the same directory. - - - - - - - It is often difficult to check whether these additional assumptions are matched, therefore this approach is not recommended. - - - - - - -
- - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/schemas.xml b/defensive-coding/tmp/en-US/xml/Tasks/schemas.xml deleted file mode 100644 index 31581c3..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/schemas.xml +++ /dev/null @@ -1,6 +0,0 @@ - - -%BOOK_ENTITIES; -]> - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-Expat-Create.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-Expat-Create.xml deleted file mode 100644 index e587406..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-Expat-Create.xml +++ /dev/null @@ -1,20 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -XML_Parser parser = XML_ParserCreate("UTF-8"); -if (parser == NULL) { - fprintf(stderr, "XML_ParserCreate failed\n"); - close(fd); - exit(1); -} -// EntityDeclHandler needs a reference to the parser to stop -// parsing. -XML_SetUserData(parser, parser); -// Disable entity processing, to inhibit entity expansion. -XML_SetEntityDeclHandler(parser, EntityDeclHandler); - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-Expat-EntityDeclHandler.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-Expat-EntityDeclHandler.xml deleted file mode 100644 index fbbfea5..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-Expat-EntityDeclHandler.xml +++ /dev/null @@ -1,19 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -// Stop the parser when an entity declaration is encountered. -static void -EntityDeclHandler(void *userData, - const XML_Char *entityName, int is_parameter_entity, - const XML_Char *value, int value_length, - const XML_Char *base, const XML_Char *systemId, - const XML_Char *publicId, const XML_Char *notationName) -{ - XML_StopParser((XML_Parser)userData, XML_FALSE); -} - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-Errors.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-Errors.xml deleted file mode 100644 index 33dc271..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-Errors.xml +++ /dev/null @@ -1,25 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -class Errors implements ErrorHandler { - @Override - public void warning(SAXParseException exception) { - exception.printStackTrace(); - } - - @Override - public void fatalError(SAXParseException exception) { - exception.printStackTrace(); - } - - @Override - public void error(SAXParseException exception) { - exception.printStackTrace(); - } -} - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-Imports.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-Imports.xml deleted file mode 100644 index e4fcf56..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-Imports.xml +++ /dev/null @@ -1,30 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -import javax.xml.XMLConstants; -import javax.xml.parsers.DocumentBuilder; -import javax.xml.parsers.DocumentBuilderFactory; -import javax.xml.parsers.ParserConfigurationException; -import javax.xml.parsers.SAXParser; -import javax.xml.parsers.SAXParserFactory; -import javax.xml.transform.dom.DOMSource; -import javax.xml.transform.sax.SAXSource; -import javax.xml.validation.Schema; -import javax.xml.validation.SchemaFactory; -import javax.xml.validation.Validator; - -import org.w3c.dom.Document; -import org.w3c.dom.ls.LSInput; -import org.w3c.dom.ls.LSResourceResolver; -import org.xml.sax.EntityResolver; -import org.xml.sax.ErrorHandler; -import org.xml.sax.InputSource; -import org.xml.sax.SAXException; -import org.xml.sax.SAXParseException; -import org.xml.sax.XMLReader; - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-NoEntityResolver.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-NoEntityResolver.xml deleted file mode 100644 index 86eb111..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-NoEntityResolver.xml +++ /dev/null @@ -1,18 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -class NoEntityResolver implements EntityResolver { - @Override - public InputSource resolveEntity(String publicId, String systemId) - throws SAXException, IOException { - // Throwing an exception stops validation. - throw new IOException(String.format( - "attempt to resolve \"%s\" \"%s\"", publicId, systemId)); - } -} - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-NoResourceResolver.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-NoResourceResolver.xml deleted file mode 100644 index 33c35bc..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK-NoResourceResolver.xml +++ /dev/null @@ -1,20 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -class NoResourceResolver implements LSResourceResolver { - @Override - public LSInput resolveResource(String type, String namespaceURI, - String publicId, String systemId, String baseURI) { - // Throwing an exception stops validation. - throw new RuntimeException(String.format( - "resolution attempt: type=%s namespace=%s " + - "publicId=%s systemId=%s baseURI=%s", - type, namespaceURI, publicId, systemId, baseURI)); - } -} - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-DOM.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-DOM.xml deleted file mode 100644 index 413e09b..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-DOM.xml +++ /dev/null @@ -1,22 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); -// Impose restrictions on the complexity of the DTD. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// Turn on validation. -// This step can be omitted if validation is not desired. -factory.setValidating(true); - -// Parse the document. -DocumentBuilder builder = factory.newDocumentBuilder(); -builder.setEntityResolver(new NoEntityResolver()); -builder.setErrorHandler(new Errors()); -Document document = builder.parse(inputStream); - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_DOM.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_DOM.xml deleted file mode 100644 index 0e06ac3..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_DOM.xml +++ /dev/null @@ -1,26 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -SchemaFactory factory = SchemaFactory.newInstance( - XMLConstants.W3C_XML_SCHEMA_NS_URI); - -// This enables restrictions on schema complexity. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// The following line prevents resource resolution -// by the schema itself. -factory.setResourceResolver(new NoResourceResolver()); - -Schema schema = factory.newSchema(schemaFile); - -Validator validator = schema.newValidator(); - -// This prevents external resource resolution. -validator.setResourceResolver(new NoResourceResolver()); -validator.validate(new DOMSource(document)); - - diff --git a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_SAX.xml b/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_SAX.xml deleted file mode 100644 index 5b16c31..0000000 --- a/defensive-coding/tmp/en-US/xml/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_SAX.xml +++ /dev/null @@ -1,29 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - -SchemaFactory factory = SchemaFactory.newInstance( - XMLConstants.W3C_XML_SCHEMA_NS_URI); - -// This enables restrictions on the schema and document -// complexity. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// This prevents resource resolution by the schema itself. -// If the schema is trusted and references additional files, -// this line must be omitted, otherwise loading these files -// will fail. -factory.setResourceResolver(new NoResourceResolver()); - -Schema schema = factory.newSchema(schemaFile); -Validator validator = schema.newValidator(); - -// This prevents external resource resolution. -validator.setResourceResolver(new NoResourceResolver()); - -validator.validate(new SAXSource(new InputSource(inputStream))); - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Author_Group.xml b/defensive-coding/tmp/en-US/xml_tmp/Author_Group.xml deleted file mode 100644 index 6b40228..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Author_Group.xml +++ /dev/null @@ -1,17 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - - Florian - Weimer - - Red Hat - Product Security Team - - fweimer@redhat.com - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Book_Info.xml b/defensive-coding/tmp/en-US/xml_tmp/Book_Info.xml deleted file mode 100644 index 6637802..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Book_Info.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - Defensive Coding - A Guide to Improving Software Security - 1.0 - 1.0 - - - - - - This document provides guidelines for improving software - security through secure coding. It covers common - programming languages and libraries, and focuses on - concrete recommendations. - - - - - - - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/Allocators.xml b/defensive-coding/tmp/en-US/xml_tmp/C/Allocators.xml deleted file mode 100644 index 974b6c1..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/Allocators.xml +++ /dev/null @@ -1,207 +0,0 @@ - - -
- Memory allocators - -
- <function>malloc</function> and related functions - - The C library interfaces for memory allocation are provided by - malloc, free and - realloc, and the - calloc function. In addition to these - generic functions, there are derived functions such as - strdup which perform allocation using - malloc internally, but do not return - untyped heap memory (which could be used for any object). - - - The C compiler knows about these functions and can use their - expected behavior for optimizations. For instance, the compiler - assumes that an existing pointer (or a pointer derived from an - existing pointer by arithmetic) will not point into the memory - area returned by malloc. - - - If the allocation fails, realloc does not - free the old pointer. Therefore, the idiom ptr = - realloc(ptr, size); is wrong because the memory - pointed to by ptr leaks in case of an error. - -
- Use-after-free errors - - After free, the pointer is invalid. - Further pointer dereferences are not allowed (and are usually - detected by valgrind). Less obvious - is that any use of the old pointer value is - not allowed, either. In particular, comparisons with any other - pointer (or the null pointer) are undefined according to the C - standard. - - - The same rules apply to realloc if the - memory area cannot be enlarged in-place. For instance, the - compiler may assume that a comparison between the old and new - pointer will always return false, so it is impossible to detect - movement this way. - -
-
- Handling memory allocation errors - - Recovering from out-of-memory errors is often difficult or even - impossible. In these cases, malloc and - other allocation functions return a null pointer. Dereferencing - this pointer lead to a crash. Such dereferences can even be - exploitable for code execution if the dereference is combined - with an array subscript. - - - In general, if you cannot check all allocation calls and - handle failure, you should abort the program on allocation - failure, and not rely on the null pointer dereference to - terminate the process. See - - for related memory allocation concerns. - -
-
- -
- <function>alloca</function> and other forms of stack-based - allocation - - Allocation on the stack is risky because stack overflow checking - is implicit. There is a guard page at the end of the memory - area reserved for the stack. If the program attempts to read - from or write to this guard page, a SIGSEGV - signal is generated and the program typically terminates. - - - This is sufficient for detecting typical stack overflow - situations such as unbounded recursion, but it fails when the - stack grows in increments larger than the size of the guard - page. In this case, it is possible that the stack pointer ends - up pointing into a memory area which has been allocated for a - different purposes. Such misbehavior can be exploitable. - - - A common source for large stack growth are calls to - alloca and related functions such as - strdupa. These functions should be avoided - because of the lack of error checking. (They can be used safely - if the allocated size is less than the page size (typically, - 4096 bytes), but this case is relatively rare.) Additionally, - relying on alloca makes it more difficult - to reorgnize the code because it is not allowed to use the - pointer after the function calling alloca - has returned, even if this function has been inlined into its - caller. - - - Similar concerns apply to variable-length - arrays (VLAs), a feature of the C99 standard which - started as a GNU extension. For large objects exceeding the - page size, there is no error checking, either. - - - In both cases, negative or very large sizes can trigger a - stack-pointer wraparound, and the stack pointer and end up - pointing into caller stack frames, which is fatal and can be - exploitable. - - - If you want to use alloca or VLAs for - performance reasons, consider using a small on-stack array (less - than the page size, large enough to fulfill most requests). If - the requested size is small enough, use the on-stack array. - Otherwise, call malloc. When exiting the - function, check if malloc had been called, - and free the buffer as needed. - -
- -
- Array allocation - - When allocating arrays, it is important to check for overflows. - The calloc function performs such checks. - - - If malloc or realloc - is used, the size check must be written manually. For instance, - to allocate an array of n elements of type - T, check that the requested size is not - greater than n / sizeof(T). - -
- -
- Custom memory allocators - - Custom memory allocates come in two forms: replacements for - malloc, and completely different interfaces - for memory management. Both approaches can reduce the - effectiveness of valgrind and similar - tools, and the heap corruption detection provided by GNU libc, so - they should be avoided. - - - Memory allocators are difficult to write and contain many - performance and security pitfalls. - - - - - When computing array sizes or rounding up allocation - requests (to the next allocation granularity, or for - alignment purposes), checks for arithmetic overflow are - required. - - - - - Size computations for array allocations need overflow - checking. See . - - - - - It can be difficult to beat well-tuned general-purpose - allocators. In micro-benchmarks, pool allocators can show - huge wins, and size-specific pools can reduce internal - fragmentation. But often, utilization of individual pools - is poor, and - - - -
- -
- Conservative garbage collection - - Garbage collection can be an alternative to explicit memory - management using malloc and - free. The Boehm-Dehmers-Weiser allocator - can be used from C programs, with minimal type annotations. - Performance is competitive with malloc on - 64-bit architectures, especially for multi-threaded programs. - The stop-the-world pauses may be problematic for some real-time - applications, though. - - - However, using a conservative garbage collector may reduce - opertunities for code reduce because once one library in a - program uses garbage collection, the whole process memory needs - to be subject to it, so that no pointers are missed. The - Boehm-Dehmers-Weiser collector also reserves certain signals for - internal use, so it is not fully transparent to the rest of the - program. - -
-
- diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/C.xml b/defensive-coding/tmp/en-US/xml_tmp/C/C.xml deleted file mode 100644 index 3dd659a..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/C.xml +++ /dev/null @@ -1,11 +0,0 @@ - - - - The C Programming Language - - - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/Language.xml b/defensive-coding/tmp/en-US/xml_tmp/C/Language.xml deleted file mode 100644 index db7cc5d..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/Language.xml +++ /dev/null @@ -1,150 +0,0 @@ - - -
- The core language - - C provides no memory safety. Most recommendations in this section - deal with this aspect of the language. - - -
- Undefined behavior - - Some C constructs are defined to be undefined by the C standard. - This does not only mean that the standard does not describe - what happens when the construct is executed. It also allows - optimizing compilers such as GCC to assume that this particular - construct is never reached. In some cases, this has caused - GCC to optimize security checks away. (This is not a flaw in GCC - or the C language. But C certainly has some areas which are more - difficult to use than others.) - - - - Common sources of undefined behavior are: - - - out-of-bounds array accesses - null pointer dereferences - overflow in signed integer arithmetic - -
- -
- Recommendations for pointers and array handling - - Always keep track of the size of the array you are working with. - Often, code is more obviously correct when you keep a pointer - past the last element of the array, and calculate the number of - remaining elements by substracting the current position from - that pointer. The alternative, updating a separate variable - every time when the position is advanced, is usually less - obviously correct. - - - - shows how to extract Pascal-style strings from a character - buffer. The two pointers kept for length checks are - inend and outend. - inp and outp are the - respective positions. - The number of input bytes is checked using the expression - len > (size_t)(inend - inp). - The cast silences a compiler warning; - inend is always larger than - inp. - - - Array processing in C - - - - It is important that the length checks always have the form - len > (size_t)(inend - inp), where - len is a variable of type - size_t which denotes the total - number of bytes which are about to be read or written next. In - general, it is not safe to fold multiple such checks into one, - as in len1 + len2 > (size_t)(inend - inp), - because the expression on the left can overflow or wrap around - (see ), and it - no longer reflects the number of bytes to be processed. - -
- -
- Recommendations for integer arithmetic - - Overflow in signed integer arithmetic is undefined. This means - that it is not possible to check for overflow after it happened, - see . - - - Incorrect overflow detection in C - - - - The following approaches can be used to check for overflow, - without actually causing it. - - - - - Use a wider type to perform the calculation, check that the - result is within bounds, and convert the result to the - original type. All intermediate results must be checked in - this way. - - - - - Perform the calculation in the corresponding unsigned type - and use bit fiddling to detect the overflow. - - - - - Compute bounds for acceptable input values which are known - to avoid overflow, and reject other values. This is the - preferred way for overflow checking on multiplications, - see . - - - - - - Overflow checking for unsigned multiplication - - - - Basic arithmetic operations a commutative, so for bounds checks, - there are two different but mathematically equivalent - expressions. Sometimes, one of the expressions results in - better code because parts of it can be reduced to a constant. - This applies to overflow checks for multiplication a * - b involving a constant a, where the - expression is reduced to b > C for some - constant C determined at compile time. The - other expression, b && a > ((unsigned)-1) / - b, is more difficult to optimize at compile time. - - - When a value is converted to a signed integer, GCC always - chooses the result based on 2's complement arithmetic. This GCC - extension (which is also implemented by other compilers) helps a - lot when implementing overflow checks. - - - Legacy code should be compiled with the - GCC option. As a result, GCC will provide 2's complement - semantics for integer arithmetic, including defined behavior on - integer overflow. - -
-
diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/Libc.xml b/defensive-coding/tmp/en-US/xml_tmp/C/Libc.xml deleted file mode 100644 index 6173bf0..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/Libc.xml +++ /dev/null @@ -1,227 +0,0 @@ - - -
- The C standard library - - Parts of the C standard library (and the UNIX and GNU extensions) - are difficult to use, so you shoud avoid them. - - - Please check the applicable documentation before using the - recommended replacements. Many of these functions allocate - buffers using malloc which your code must - deallocate explicitly using free. - -
- Absolutely banned interfaces - - The functions listed below must not be used because they are - almost always unsafe. Use the indicated replacements instead. - - - gets - ⟶ fgets - getwd - ⟶ getcwd - or get_current_dir_name - - - readdir_r ⟶ readdir - - - - - - - realpath (with a non-NULL second parameter) - ⟶ realpath with NULL as the second parameter, - or canonicalize_file_name - - - - - - - The constants listed below must not be used, either. Instead, - code must allocate memory dynamically and use interfaces with - length checking. - - - - - NAME_MAX (limit not actually enforced by - the kernel) - - - - - PATH_MAX (limit not actually enforced by - the kernel) - - - - - _PC_NAME_MAX (This limit, returned by the - pathconf function, is not enforced by - the kernel.) - - - - - _PC_PATH_MAX (This limit, returned by the - pathconf function, is not enforced by - the kernel.) - - - - - The following structure members must not be used. - - - - - f_namemax in struct - statvfs (limit not actually enforced by the kernel, - see _PC_NAME_MAX above) - - - -
-
- Functions to avoid - - The following string manipulation functions can be used securely - in principle, but their use should be avoided because they are - difficult to use correctly. Calls to these functions can be - replaced with asprintf or - vasprintf. (For non-GNU targets, these - functions are available from Gnulib.) In some cases, the - snprintf function might be a suitable - replacement, see . - - - sprintf - strcat - strcpy - vsprintf - - - Use the indicated replacements for the functions below. - - - - - alloca ⟶ - malloc and free - (see ) - - - - - putenv ⟶ - explicit envp argument in process creation - (see ) - - - - - setenv ⟶ - explicit envp argument in process creation - (see ) - - - - - strdupa ⟶ - strdup and free - (see ) - - - - - strndupa ⟶ - strndup and free - (see ) - - - - - system ⟶ - posix_spawn - or fork/execve/ - (see ) - - - - - unsetenv ⟶ - explicit envp argument in process creation - (see ) - - - -
-
- String Functions With Explicit Length Arguments - - The snprintf function provides a way to - construct a string in a statically-sized buffer. (If the buffer - size is dynamic, use asprintf instead.) - - - - - - The second argument to the snprintf should - always be the size of the buffer in the first argument (which - should be a character array). Complex pointer and length - arithmetic can introduce errors and nullify the security - benefits of snprintf. If you need to - construct a string iteratively, by repeatedly appending - fragments, consider constructing the string on the heap, - increasing the buffer with realloc as - needed. (snprintf does not support - overlapping the result buffer with argument strings.) - - - If you use vsnprintf (or - snprintf) with a format string which is not - a constant, but a function argument, it is important to annotate - the function with a format function - attribute, so that GCC can warn about misuse of your function - (see ). - - - The <literal>format</literal> function attribute - - - - There are other functions which operator on NUL-terminated - strings and take a length argument which affects the number of - bytes written to the destination: strncpy, - strncat, and stpncpy. - These functions do not ensure that the result string is - NUL-terminated. For strncpy, - NUL termination can be added this way: - - - - - - Some systems support strlcpy and - strlcat functions which behave this way, - but these functions are not part of GNU libc. Using - snprintf with a suitable format string is a - simple (albeit slightly slower) replacement. - -
-
diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/schemas.xml b/defensive-coding/tmp/en-US/xml_tmp/C/schemas.xml deleted file mode 100644 index 8e84245..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/schemas.xml +++ /dev/null @@ -1,4 +0,0 @@ - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Arithmetic-add.xml b/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Arithmetic-add.xml deleted file mode 100644 index 3c67512..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Arithmetic-add.xml +++ /dev/null @@ -1,21 +0,0 @@ - - - - -void report_overflow(void); - -int -add(int a, int b) -{ - int result = a + b; - if (a < 0 || b < 0) { - return -1; - } - // The compiler can optimize away the following if statement. - if (result < 0) { - report_overflow(); - } - return result; -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Arithmetic-mult.xml b/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Arithmetic-mult.xml deleted file mode 100644 index ecb27a0..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Arithmetic-mult.xml +++ /dev/null @@ -1,14 +0,0 @@ - - - - -unsigned -mul(unsigned a, unsigned b) -{ - if (b && a > ((unsigned)-1) / b) { - report_overflow(); - } - return a * b; -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Pointers-remaining.xml b/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Pointers-remaining.xml deleted file mode 100644 index f527d03..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/Pointers-remaining.xml +++ /dev/null @@ -1,49 +0,0 @@ - - - - -ssize_t -extract_strings(const char *in, size_t inlen, char **out, size_t outlen) -{ - const char *inp = in; - const char *inend = in + inlen; - char **outp = out; - char **outend = out + outlen; - - while (inp != inend) { - size_t len; - char *s; - if (outp == outend) { - errno = ENOSPC; - goto err; - } - len = (unsigned char)*inp; - ++inp; - if (len > (size_t)(inend - inp)) { - errno = EINVAL; - goto err; - } - s = malloc(len + 1); - if (s == NULL) { - goto err; - } - memcpy(s, inp, len); - inp += len; - s[len] = '\0'; - *outp = s; - ++outp; - } - return outp - out; -err: - { - int errno_old = errno; - while (out != outp) { - free(*out); - ++out; - } - errno = errno_old; - } - return -1; -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-format.xml b/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-format.xml deleted file mode 100644 index 519f127..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-format.xml +++ /dev/null @@ -1,18 +0,0 @@ - - - - -void log_format(const char *format, ...) __attribute__((format(printf, 1, 2))); - -void -log_format(const char *format, ...) -{ - char buf[1000]; - va_list ap; - va_start(ap, format); - vsnprintf(buf, sizeof(buf), format, ap); - va_end(ap); - log_string(buf); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-snprintf.xml b/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-snprintf.xml deleted file mode 100644 index dc790d8..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-snprintf.xml +++ /dev/null @@ -1,8 +0,0 @@ - - - - -char fraction[30]; -snprintf(fraction, sizeof(fraction), "%d/%d", numerator, denominator); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-strncpy.xml b/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-strncpy.xml deleted file mode 100644 index bdbdd08..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/C/snippets/String-Functions-strncpy.xml +++ /dev/null @@ -1,9 +0,0 @@ - - - - -char buf[10]; -strncpy(buf, data, sizeof(buf)); -buf[sizeof(buf) - 1] = '\0'; - diff --git a/defensive-coding/tmp/en-US/xml_tmp/CXX/CXX.xml b/defensive-coding/tmp/en-US/xml_tmp/CXX/CXX.xml deleted file mode 100644 index fccfb75..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/CXX/CXX.xml +++ /dev/null @@ -1,10 +0,0 @@ - - - - The C++ Programming Language - - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/CXX/Language.xml b/defensive-coding/tmp/en-US/xml_tmp/CXX/Language.xml deleted file mode 100644 index 9dbc4f3..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/CXX/Language.xml +++ /dev/null @@ -1,186 +0,0 @@ - - -
- The core language - - C++ includes a large subset of the C language. As far as the C - subset is used, the recommendations in apply. - - -
- Array allocation with <literal>operator new[]</literal> - - For very large values of n, an expression - like new T[n] can return a pointer to a heap - region which is too small. In other words, not all array - elements are actually backed with heap memory reserved to the - array. Current GCC versions generate code that performs a - computation of the form sizeof(T) * size_t(n) + - cookie_size, where cookie_size is - currently at most 8. This computation can overflow, and - GCC-generated code does not detect this. - - - The std::vector template can be used instead - an explicit array allocation. (The GCC implementation detects - overflow internally.) - - - If there is no alternative to operator new[], - code which allocates arrays with a variable length must check - for overflow manually. For the new T[n] - example, the size check could be n || (n > 0 && - n > (size_t(-1) - 8) / sizeof(T)). (See .) If there are - additional dimensions (which must be constants according to the - C++ standard), these should be included as factors in the - divisor. - - - These countermeasures prevent out-of-bounds writes and potential - code execution. Very large memory allocations can still lead to - a denial of service. - contains suggestions for mitigating this problem when processing - untrusted data. - - - See - for array allocation advice for C-style memory allocation. - -
- -
- Overloading - - Do not overload functions with versions that have different - security characteristics. For instance, do not implement a - function strcat which works on - std::string arguments. Similarly, do not name - methods after such functions. - -
-
- ABI compatibility and preparing for security updates - - A stable binary interface (ABI) is vastly preferred for security - updates. Without a stable ABI, all reverse dependencies need - recompiling, which can be a lot of work and could even be - impossible in some cases. Ideally, a security update only - updates a single dynamic shared object, and is picked up - automatically after restarting affected processes. - - - Outside of extremely performance-critical code, you should - ensure that a wide range of changes is possible without breaking - ABI. Some very basic guidelines are: - - - - - Avoid inline functions. - - - - - Use the pointer-to-implementation idiom. - - - - - Try to avoid templates. Use them if the increased type - safety provides a benefit to the programmer. - - - - - Move security-critical code out of templated code, so that - it can be patched in a central place if necessary. - - - - - The KDE project publishes a document with more extensive - guidelines on ABI-preserving changes to C++ code, Policies/Binary - Compatibility Issues With C++ - (d-pointer refers to the - pointer-to-implementation idiom). - -
- -
- C++0X and C++11 support - - GCC offers different language compatibility modes: - - - - - for the original 1998 C++ - standard - - - - - for the 1998 standard with the - changes from the TR1 technical report - - - - - for the 2011 C++ standard. This - option should not be used. - - - - - for several different versions - of C++11 support in development, depending on the GCC - version. This option should not be used. - - - - - - For each of these flags, there are variants which also enable - GNU extensions (mostly language features also found in C99 or - C11): , - , . - Again, should not be used. - - - If you enable C++11 support, the ABI of the standard C++ library - libstdc++ will change in subtle ways. - Currently, no C++ libraries are compiled in C++11 mode, so if - you compile your code in C++11 mode, it will be incompatible - with the rest of the system. Unfortunately, this is also the - case if you do not use any C++11 features. Currently, there is - no safe way to enable C++11 mode (except for freestanding - applications). - - - The meaning of C++0X mode changed from GCC release to GCC - release. Earlier versions were still ABI-compatible with C++98 - mode, but in the most recent versions, switching to C++0X mode - activates C++11 support, with its compatibility problems. - - - Some C++11 features (or approximations thereof) are available - with TR1 support, that is, with or - and in the - <tr1/*> header files. This includes - std::tr1::shared_ptr (from - <tr1/memory>) and - std::tr1::function (from - <tr1/functional>). For other C++11 - features, the Boost C++ library contains replacements. - -
-
- diff --git a/defensive-coding/tmp/en-US/xml_tmp/CXX/Std.xml b/defensive-coding/tmp/en-US/xml_tmp/CXX/Std.xml deleted file mode 100644 index 5ed53a4..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/CXX/Std.xml +++ /dev/null @@ -1,32 +0,0 @@ - - -
- The C++ standard library - - The C++ standard library includes most of its C counterpart - by reference, see . - -
- Containers and <literal>operator[]</literal> - - Many containers similar to std::vector - provide both operator[](size_type) and a - member function at(size_type). This applies - to std::vector itself, - std::array, std::string - and other instances of std::basic_string. - - - operator[](size_type) is not required by the - standard to perform bounds checking (and the implementation in - GCC does not). In contrast, at(size_type) - must perform such a check. Therefore, in code which is not - performance-critical, you should prefer - at(size_type) over - operator[](size_type), even though it is - slightly more verbose. - -
-
- diff --git a/defensive-coding/tmp/en-US/xml_tmp/CXX/schemas.xml b/defensive-coding/tmp/en-US/xml_tmp/CXX/schemas.xml deleted file mode 100644 index 8e84245..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/CXX/schemas.xml +++ /dev/null @@ -1,4 +0,0 @@ - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Defensive_Coding.ent b/defensive-coding/tmp/en-US/xml_tmp/Defensive_Coding.ent deleted file mode 100644 index 0bf84b7..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Defensive_Coding.ent +++ /dev/null @@ -1,2 +0,0 @@ - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Defensive_Coding.xml b/defensive-coding/tmp/en-US/xml_tmp/Defensive_Coding.xml deleted file mode 100644 index cef4bbf..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Defensive_Coding.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - - - Programming Languages - - - - - - Specific Programming Tasks - - - - - - - - - - Implementing Security Features - - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/Authentication.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/Authentication.xml deleted file mode 100644 index c32792a..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/Authentication.xml +++ /dev/null @@ -1,189 +0,0 @@ - - - - Authentication and Authorization - -
- Authenticating servers - - When connecting to a server, a client has to make sure that it - is actually talking to the server it expects. There are two - different aspects, securing the network path, and making sure - that the expected user runs the process on the target host. - There are several ways to ensure that: - - - - - The server uses a TLS certificate which is valid according - to the web browser public key infrastructure, and the client - verifies the certificate and the host name. - - - - - The server uses a TLS certificate which is expectedby the - client (perhaps it is stored in a configuration file read by - the client). In this case, no host name checking is - required. - - - - - On Linux, UNIX domain sockets (of the - PF_UNIX protocol family, sometimes called - PF_LOCAL) are restricted by file system - permissions. If the server socket path is not - world-writable, the server identity cannot be spoofed by - local users. - - - - - Port numbers less than 1024 (trusted - ports) can only be used by - root, so if a UDP or TCP server is - running on the local host and it uses a trusted port, its - identity is assured. (Not all operating systems enforce the - trusted ports concept, and the network might not be trusted, - so it is only useful on the local system.) - - - - - TLS () is the - recommended way for securing connections over untrusted - networks. - - - If the server port number is 1024 is higher, a local user can - impersonate the process by binding to this socket, perhaps after - crashing the real server by exploiting a denial-of-service - vulnerability. - -
- -
- Host-based authentication - - Host-based authentication uses access control lists (ACLs) to - accept or deny requests from clients. Thsis authentication - method comes in two flavors: IP-based (or, more generally, - address-based) and name-based (with the name coming from DNS or - /etc/hosts). IP-based ACLs often use - prefix notation to extend access to entire subnets. Name-based - ACLs sometimes use wildcards for adding groups of hosts (from - entire DNS subtrees). (In the SSH context, host-based - authentication means something completely different and is not - covered in this section.) - - - Host-based authentication trust the network and may not offer - sufficient granularity, so it has to be considered a weak form - of authentication. On the other hand, IP-based authentication - can be made extremely robust and can be applied very early in - input processing, so it offers an opportunity for significantly - reducing the number of potential attackers for many services. - - - The names returned by gethostbyaddr and - getnameinfo functions cannot be trusted. - (DNS PTR records can be set to arbitrary values, not just names - belong to the address owner.) If these names are used for ACL - matching, a forward lookup using - gethostbyaddr or - getaddrinfo has to be performed. The name - is only valid if the original address is found among the results - of the forward lookup (double-reverse - lookup). - - - An empty ACL should deny all access (deny-by-default). If empty - ACLs permits all access, configuring any access list must switch - to deny-by-default for all unconfigured protocols, in both - name-based and address-based variants. - - - Similarly, if an address or name is not matched by the list, it - should be denied. However, many implementations behave - differently, so the actual behavior must be documented properly. - - - IPv6 addresses can embed IPv4 addresses. There is no - universally correct way to deal with this ambiguity. The - behavior of the ACL implementation should be documented. - -
- -
- UNIX domain socket authentication - - UNIX domain sockets (with address family - AF_UNIX or AF_LOCAL) are - restricted to the local host and offer a special authentication - mechanism: credentials passing. - - - Nowadays, most systems support the - SO_PEERCRED (Linux) or - LOCAL_PEERCRED (FreeBSD) socket options, or - the getpeereid (other BSDs, MacOS X). - These interfaces provide direct access to the (effective) user - ID on the other end of a domain socket connect, without - cooperation from the other end. - - - Historically, credentials passing was implemented using - ancillary data in the sendmsg and - recvmsg functions. On some systems, only - credentials data that the peer has explicitly sent can be - received, and the kernel checks the data for correctness on the - sending side. This means that both peers need to deal with - ancillary data. Compared to that, the modern interfaces are - easier to use. Both sets of interfaces vary considerably among - UNIX-like systems, unfortunately. - - - If you want to authenticate based on supplementary groups, you - should obtain the user ID using one of these methods, and look - up the list of supplementary groups using - getpwuid (or - getpwuid_r) and - getgrouplist. Using the PID and - information from /proc/PID/status is prone - to race conditions and insecure. - -
- - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/TLS.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/TLS.xml deleted file mode 100644 index a0432f5..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/TLS.xml +++ /dev/null @@ -1,988 +0,0 @@ - - - - Transport Layer Security - - Transport Layer Security (TLS, formerly Secure Sockets - Layer/SSL) is the recommended way to to protect integrity and - confidentiality while data is transferred over an untrusted - network connection, and to identify the endpoint. - -
- Common Pitfalls - - TLS implementations are difficult to use, and most of them lack - a clean API design. The following sections contain - implementation-specific advice, and some generic pitfalls are - mentioned below. - - - - - Most TLS implementations have questionable default TLS - cipher suites. Most of them enable anonymous Diffie-Hellman - key exchange (but we generally want servers to authenticate - themselves). Many do not disable ciphers which are subject - to brute-force attacks because of restricted key lengths. - Some even disable all variants of AES in the default - configuration. - - - When overriding the cipher suite defaults, it is recommended - to disable all cipher suites which are not present on a - whitelist, instead of simply enabling a list of cipher - suites. This way, if an algorithm is disabled by default in - the TLS implementation in a future security update, the - application will not re-enable it. - - - - - The name which is used in certificate validation must match - the name provided by the user or configuration file. No host - name canonicalization or IP address lookup must be performed. - - - - - The TLS handshake has very poor performance if the TCP Nagle - algorithm is active. You should switch on the - TCP_NODELAY socket option (at least for the - duration of the handshake), or use the Linux-specific - TCP_CORK option. - - - Deactivating the TCP Nagle algorithm - - - - - - Implementing proper session resumption decreases handshake - overhead considerably. This is important if the upper-layer - protocol uses short-lived connections (like most application - of HTTPS). - - - - - Both client and server should work towards an orderly - connection shutdown, that is send - close_notify alerts and respond to them. - This is especially important if the upper-layer protocol - does not provide means to detect connection truncation (like - some uses of HTTP). - - - - - When implementing a server using event-driven programming, - it is important to handle the TLS handshake properly because - it includes multiple network round-trips which can block - when an ordinary TCP accept would not. - Otherwise, a client which fails to complete the TLS - handshake for some reason will prevent the server from - handling input from other clients. - - - - - Unlike regular file descriptors, TLS connections cannot be - passed between processes. Some TLS implementations add - additional restrictions, and TLS connections generally - cannot be used across fork function - calls (see ). - - - -
- OpenSSL Pitfalls - - Some OpenSSL function use tri-state return - values. Correct error checking is extremely - important. Several functions return int - values with the following meaning: - - - - - The value 1 indicates success (for - example, a successful signature verification). - - - - - The value 0 indicates semantic - failure (for example, a signature verification which was - unsuccessful because the signing certificate was - self-signed). - - - - - The value -1 indicates a low-level - error in the system, such as failure to allocate memory - using malloc. - - - - - Treating such tri-state return values as booleans can lead - to security vulnerabilities. Note that some OpenSSL - functions return boolean results or yet another set of - status indicators. Each function needs to be checked - individually. - - - Recovering precise error information is difficult. - - shows how to obtain a more precise error code after a function - call on an SSL object has failed. However, - there are still cases where no detailed error information is - available (e.g., if SSL_shutdown fails - due to a connection teardown by the other end). - - - Obtaining OpenSSL error codes - - - - The OPENSSL_config function is - documented to never fail. In reality, it can terminate the - entire process if there is a failure accessing the - configuration file. An error message is written to standard - error, but which might not be visible if the function is - called from a daemon process. - - - OpenSSL contains two separate ASN.1 DER decoders. One set - of decoders operate on BIO handles (the input/output stream - abstraction provided by OpenSSL); their decoder function - names start with d2i_ and end in - _fp or _bio (e.g., - d2i_X509_fp or - d2i_X509_bio). These decoders must not - be used for parsing data from untrusted sources; instead, - the variants without the _fp and - _bio (e.g., - d2i_X509) shall be used. The BIO - variants have received considerably less testing and are not - very robust. - - - For the same reason, the OpenSSL command line tools (such as - openssl x509) are generally generally less - robust than the actual library code. They use the BIO - functions internally, and not the more robust variants. - - - The command line tools do not always indicate failure in the - exit status of the openssl process. - For instance, a verification failure in openssl - verify result in an exit status of zero. - - - The OpenSSL server and client applications (openssl - s_client and openssl s_server) - are debugging tools and should never be - used as generic clients. For instance, the - s_client tool reacts in a - surprisign way to lines starting with R and - Q. - - - OpenSSL allows application code to access private key - material over documented interfaces. This can significantly - increase the part of the code base which has to undergo - security certification. - -
-
- GNUTLS Pitfalls - - libgnutls.so.26 links to - libpthread.so.0. Loading the threading - library too late causes problems, so the main program should - be linked with -lpthread as well. As a - result, it can be difficult to use GNUTLS in a plugin which is - loaded with the dlopen function. Another - side effect is that applications which merely link against - GNUTLS (even without actually using it) may incur a - substantial overhead because other libraries automatically - switch to thread-safe algorithms. - - - The gnutls_global_init function must be - called before using any functionality provided by the library. - This function is not thread-safe, so external locking is - required, but it is not clear which lock should be used. - Omitting the synchronization does not just lead to a memory - leak, as it is suggested in the GNUTLS documentation, but to - undefined behavior because there is no barrier that would - enforce memory ordering. - - - The gnutls_global_deinit function does - not actually deallocate all resources allocated by - gnutls_global_init. It is currently not - thread-safe. Therefore, it is best to avoid calling it - altogether. - - - The X.509 implementation in GNUTLS is rather lenient. For - example, it is possible to create and process X.509 - version 1 certificates which carry extensions. These - certificates are (correctly) rejected by other - implementations. - -
-
- OpenJDK Pitfalls - - The Java cryptographic framework is highly modular. As a - result, when you request an object implementing some - cryptographic functionality, you cannot be completely sure - that you end up with the well-tested, reviewed implementation - in OpenJDK. - - - OpenJDK (in the source code as published by Oracle) and other - implementations of the Java platform require that the system - administrator has installed so-called unlimited - strength jurisdiction policy files. Without this - step, it is not possible to use the secure algorithms which - offer sufficient cryptographic strength. Most downstream - redistributors of OpenJDK remove this requirement. - - - Some versions of OpenJDK use /dev/random - as the randomness source for nonces and other random data - which is needed for TLS operation, but does not actually - require physical randomness. As a result, TLS applications - can block, waiting for more bits to become available in - /dev/random. - -
-
- NSS Pitfalls - - NSS was not designed to be used by other libraries which can - be linked into applications without modifying them. There is - a lot of global state. There does not seem to be a way to - perform required NSS initialization without race conditions. - - - If the NSPR descriptor is in an unexpected state, the - SSL_ForceHandshake function can succeed, - but no TLS handshake takes place, the peer is not - authenticated, and subsequent data is exchanged in the clear. - - - NSS disables itself if it detects that the process underwent a - fork after the library has been - initialized. This behavior is required by the PKCS#11 API - specification. - -
-
-
- TLS Clients - - Secure use of TLS in a client generally involves all of the - following steps. (Individual instructions for specific TLS - implementations follow in the next sections.) - - - - - The client must configure the TLS library to use a set of - trusted root certificates. These certificates are provided - by the system in /etc/ssl/certs or files derived - from it. - - - - - The client selects sufficiently strong cryptographic - primitives and disables insecure ones (such as no-op - encryption). Compression and SSL version 2 support must be - disabled (including the SSLv2-compatible handshake). - - - - - The client initiates the TLS connection. The Server Name - Indication extension should be used if supported by the - TLS implementation. Before switching to the encrypted - connection state, the contents of all input and output - buffers must be discarded. - - - - - The client needs to validate the peer certificate provided - by the server, that is, the client must check that there - is a cryptographically protected chain from a trusted root - certificate to the peer certificate. (Depending on the - TLS implementation, a TLS handshake can succeed even if - the certificate cannot be validated.) - - - - - The client must check that the configured or user-provided - server name matches the peer certificate provided by the - server. - - - - - It is safe to provide users detailed diagnostics on - certificate validation failures. Other causes of handshake - failures and, generally speaking, any details on other errors - reported by the TLS implementation (particularly exception - tracebacks), must not be divulged in ways that make them - accessible to potential attackers. Otherwise, it is possible - to create decryption oracles. - - - - Depending on the application, revocation checking (against - certificate revocations lists or via OCSP) and session - resumption are important aspects of production-quality - client. These aspects are not yet covered. - - -
- Implementation TLS Clients With OpenSSL - - In the following code, the error handling is only exploratory. - Proper error handling is required for production use, - especially in libraries. - - - - The OpenSSL library needs explicit initialization (see ). - - - OpenSSL library initialization - - - - After that, a context object has to be created, which acts as - a factory for connection objects (). We - use an explicit cipher list so that we do not pick up any - strange ciphers when OpenSSL is upgraded. The actual version - requested in the client hello depends on additional - restrictions in the OpenSSL library. If possible, you should - follow the example code and use the default list of trusted - root certificate authorities provided by the system because - you would have to maintain your own set otherwise, which can - be cumbersome. - - - OpenSSL client context creation - - - - A single context object can be used to create multiple - connection objects. It is safe to use the same - SSL_CTX object for creating connections - concurrently from multiple threads, provided that the - SSL_CTX object is not modified (e.g., - callbacks must not be changed). - - - After creating the TCP socket and disabling the Nagle - algorithm (per ), the actual - connection object needs to be created, as show in . If - the handshake started by SSL_connect - fails, the ssl_print_error_and_exit - function from is called. - - - The certificate_validity_override - function provides an opportunity to override the validity of - the certificate in case the OpenSSL check fails. If such - functionality is not required, the call can be removed, - otherwise, the application developer has to implement it. - - - The host name passed to the functions - SSL_set_tlsext_host_name and - X509_check_host must be the name that was - passed to getaddrinfo or a similar name - resolution function. No host name canonicalization must be - performed. The X509_check_host function - used in the final step for host name matching is currently - only implemented in OpenSSL 1.1, which is not released yet. - In case host name matching fails, the function - certificate_host_name_override is called. - This function should check user-specific certificate store, to - allow a connection even if the host name does not match the - certificate. This function has to be provided by the - application developer. Note that the override must be keyed - by both the certificate and the host - name. - - - Creating a client connection using OpenSSL - - - - The connection object can be used for sending and receiving - data, as in . - It is also possible to create a BIO object - and use the SSL object as the underlying - transport, using BIO_set_ssl. - - - Using an OpenSSL connection to send and receive data - - - - When it is time to close the connection, the - SSL_shutdown function needs to be called - twice for an orderly, synchronous connection termination - (). - This exchanges close_notify alerts with the - server. The additional logic is required to deal with an - unexpected close_notify from the server. - Note that is necessary to explicitly close the underlying - socket after the connection object has been freed. - - - Closing an OpenSSL connection in an orderly fashion - - - - shows how - to deallocate the context object when it is no longer needed - because no further TLS connections will be established. - - - Closing an OpenSSL connection in an orderly fashion - - -
-
- Implementation TLS Clients With GNUTLS - - This section describes how to implement a TLS client with full - certificate validation (but without certificate revocation - checking). Note that the error handling in is only - exploratory and needs to be replaced before production use. - - - The GNUTLS library needs explicit initialization: - - - - - - Failing to do so can result in obscure failures in Base64 - decoding. See for - additional aspects of initialization. - - - Before setting up TLS connections, a credentials objects has - to be allocated and initialized with the set of trusted root - CAs (). - - - Initializing a GNUTLS credentials structure - - - - After the last TLS connection has been closed, this credentials - object should be freed: - - - - - - During its lifetime, the credentials object can be used to - initialize TLS session objects from multiple threads, provided - that it is not changed. - - - Once the TCP connection has been established, the Nagle - algorithm should be disabled (see ). After that, the - socket can be associated with a new GNUTLS session object. - The previously allocated credentials object provides the set - of root CAs. The NORMAL set of cipher - suites and protocols provides a reasonable default. Then the - TLS handshake must be initiated. This is shown in . - - - Establishing a TLS client connection using GNUTLS - - - - After the handshake has been completed, the server certificate - needs to be verified (). In - the example, the user-defined - certificate_validity_override function is - called if the verification fails, so that a separate, - user-specific trust store can be checked. This function call - can be omitted if the functionality is not needed. - - - Verifying a server certificate using GNUTLS - - - - In the next step (, the - certificate must be matched against the host name (note the - unusual return value from - gnutls_x509_crt_check_hostname). Again, - an override function - certificate_host_name_override is called. - Note that the override must be keyed to the certificate - and the host name. The function call can - be omitted if the override is not needed. - - - Matching the server host name and certificate in a - GNUTLS client - - - - In newer GNUTLS versions, certificate checking and host name - validation can be combined using the - gnutls_certificate_verify_peers3 function. - - - An established TLS session can be used for sending and - receiving data, as in . - - - Using a GNUTLS session - - - - In order to shut down a connection in an orderly manner, you - should call the gnutls_bye function. - Finally, the session object can be deallocated using - gnutls_deinit (see ). - - - Using a GNUTLS session - - -
-
- Implementing TLS Clients With OpenJDK - - The examples below use the following cryptographic-related - classes: - - - - - - If compatibility with OpenJDK 6 is required, it is necessary - to use the internal class - sun.security.util.HostnameChecker. (The - public OpenJDK API does not provide any support for dissecting - the subject distinguished name of an X.509 certificate, so a - custom-written DER parser is needed—or we have to use an - internal class, which we do below.) In OpenJDK 7, the - setEndpointIdentificationAlgorithm method - was added to the - javax.net.ssl.SSLParameters class, - providing an official way to implement host name checking. - - - TLS connections are established using an - SSLContext instance. With a properly - configured OpenJDK installation, the - SunJSSE provider uses the system-wide set - of trusted root certificate authorities, so no further - configuration is necessary. For backwards compatibility with - OpenJDK 6, the TLSv1 provider has to - be supported as a fall-back option. This is shown in . - - - Setting up an <literal>SSLContext</literal> for OpenJDK TLS - clients - - - - In addition to the context, a TLS parameter object will be - needed which adjusts the cipher suites and protocols (). Like - the context, these parameters can be reused for multiple TLS - connections. - - - Setting up <literal>SSLParameters</literal> for TLS use - with OpenJDK - - - - As initialized above, the parameter object does not yet - require host name checking. This has to be enabled - separately, and this is only supported by OpenJDK 7 and later: - - - - - - All application protocols can use the - "HTTPS" algorithm. (The algorithms have - minor differences with regard to wildcard handling, which - should not matter in practice.) - - - - shows how to establish the connection. Before the handshake - is initialized, the protocol and cipher configuration has to - be performed, by applying the parameter object - params. (After this point, changes to - params will not affect this TLS socket.) - As mentioned initially, host name checking requires using an - internal API on OpenJDK 6. - - - Establishing a TLS connection with OpenJDK - - - - Starting with OpenJDK 7, the last lines can be omitted, - provided that host name verification has been enabled by - calling the - setEndpointIdentificationAlgorithm method - on the params object (before it was applied - to the socket). - - - The TLS socket can be used as a regular socket, as shown in - . - - - Using a TLS client socket in OpenJDK - - -
- Overriding server certificate validation with OpenJDK 6 - - Overriding certificate validation requires a custom trust - manager. With OpenJDK 6, the trust manager lacks - information about the TLS session, and to which server the - connection is made. Certificate overrides have to be tied - to specific servers (host names). Consequently, different - TrustManager and - SSLContext objects have to be used for - different servers. - - - In the trust manager shown in , - the server certificate is identified by its SHA-256 hash. - - - A customer trust manager for OpenJDK TLS clients - - - - This trust manager has to be passed to the - init method of the - SSLContext object, as show in . - - - Using a custom TLS trust manager with OpenJDK - - - - When certificate overrides are in place, host name - verification should not be performed because there is no - security requirement that the host name in the certificate - matches the host name used to establish the connection (and - it often will not). However, without host name - verification, it is not possible to perform transparent - fallback to certification validation using the system - certificate store. - - - The approach described above works with OpenJDK 6 and later - versions. Starting with OpenJDK 7, it is possible to use a - custom subclass of the - javax.net.ssl.X509ExtendedTrustManager - class. The OpenJDK TLS implementation will call the new - methods, passing along TLS session information. This can be - used to implement certificate overrides as a fallback (if - certificate or host name verification fails), and a trust - manager object can be used for multiple servers because the - server address is available to the trust manager. - -
-
-
- Implementing TLS Clients With NSS - - The following code shows how to implement a simple TLS client - using NSS. Note that the error handling needs replacing - before production use. - - - Using NSS needs several header files, as shown in - . - - - Include files for NSS - - - - Initializing the NSS library is a complex task (). It is not - thread-safe. By default, the library is in export mode, and - all strong ciphers are disabled. Therefore, after creating - the NSSInitCContext object, we probe all - the strong ciphers we want to use, and check if at least one - of them is available. If not, we call - NSS_SetDomesticPolicy to switch to - unrestricted policy mode. This function replaces the existing - global cipher suite policy, that is why we avoid calling it - unless absolutely necessary. - - - The simplest way to configured the trusted root certificates - involves loading the libnssckbi.so NSS - module with a call to the - SECMOD_LoadUserModule function. The root - certificates are compiled into this module. (The PEM module - for NSS, libnsspem.so, offers a way to - load trusted CA certificates from a file.) - - - Initializing the NSS library - - - - Some of the effects of the initialization can be reverted with - the following function calls: - - - - - - After NSS has been initialized, the TLS connection can be - created (). The - internal PR_ImportTCPSocket function is - used to turn the POSIX file descriptor - sockfd into an NSPR file descriptor. (This - function is de-facto part of the NSS public ABI, so it will - not go away.) Creating the TLS-capable file descriptor - requires a model descriptor, which is - configured with the desired set of protocols and ciphers. - (The good_ciphers variable is part of .) We cannot - resort to disabling ciphers not on a whitelist because by - default, the AES cipher suites are disabled. The model - descriptor is not needed anymore after TLS support has been - activated for the existing connection descriptor. - - - The call to SSL_BadCertHook can be - omitted if no mechanism to override certificate verification - is needed. The bad_certificate function - must check both the host name specified for the connection and - the certificate before granting the override. - - - Triggering the actual handshake requires three function calls, - SSL_ResetHandshake, - SSL_SetURL, and - SSL_ForceHandshake. (If - SSL_ResetHandshake is omitted, - SSL_ForceHandshake will succeed, but the - data will not be encrypted.) During the handshake, the - certificate is verified and matched against the host name. - - - Creating a TLS connection with NSS - - - - After the connection has been established, shows how to use - the NSPR descriptor to communicate with the server. - - - Using NSS for sending and receiving data - - - - - shows how to close the connection. - - - Closing NSS client connections - - -
-
- Implementing TLS Clients With Python - - The Python distribution provides a TLS implementation in the - ssl module (actually a wrapper around - OpenSSL). The exported interface is somewhat restricted, so - that the client code shown below does not fully implement the - recommendations in . - - - - Currently, most Python function which accept - https:// URLs or otherwise implement - HTTPS support do not perform certificate validation at all. - (For example, this is true for the httplib - and xmlrpclib modules.) If you use - HTTPS, you should not use the built-in HTTP clients. The - Curl class in the curl - module, as provided by the python-pycurl - package implements proper certificate validation. - - - - The ssl module currently does not perform - host name checking on the server certificate. - shows how to implement certificate matching, using the parsed - certificate returned by getpeercert. - - - Implementing TLS host name checking Python (without - wildcard support) - - - - To turn a regular, connected TCP socket into a TLS-enabled - socket, use the ssl.wrap_socket function. - The function call in - provides additional arguments to override questionable - defaults in OpenSSL and in the Python module. - - - - - ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5" - selects relatively strong cipher suites with - certificate-based authentication. (The call to - check_host_name function provides - additional protection against anonymous cipher suites.) - - - - - ssl_version=ssl.PROTOCOL_TLSv1 disables - SSL 2.0 support. By default, the ssl - module sends an SSL 2.0 client hello, which is rejected by - some servers. Ideally, we would request OpenSSL to - negotiated the most recent TLS version supported by the - server and the client, but the Python module does not - allow this. - - - - - cert_reqs=ssl.CERT_REQUIRED turns on - certificate validation. - - - - - ca_certs='/etc/ssl/certs/ca-bundle.crt' - initializes the certificate store with a set of trusted - root CAs. Unfortunately, it is necessary to hard-code - this path into applications because the default path in - OpenSSL is not available through the Python - ssl module. - - - - - The ssl module (and OpenSSL) perform - certificate validation, but the certificate must be compared - manually against the host name, by calling the - check_host_name defined above. - - - Establishing a TLS client connection with Python - - - - After the connection has been established, the TLS socket can - be used like a regular socket: - - - - - - Closing the TLS socket is straightforward as well: - - - - -
-
- diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/schemas.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/schemas.xml deleted file mode 100644 index 8e84245..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/schemas.xml +++ /dev/null @@ -1,4 +0,0 @@ - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Connect.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Connect.xml deleted file mode 100644 index fbf1420..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Connect.xml +++ /dev/null @@ -1,50 +0,0 @@ - - - - -// Create the session object. -gnutls_session_t session; -ret = gnutls_init(&session, GNUTLS_CLIENT); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_init: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Configure the cipher preferences. -const char *errptr = NULL; -ret = gnutls_priority_set_direct(session, "NORMAL", &errptr); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_priority_set_direct: %s\n" - "error: at: \"%s\"\n", gnutls_strerror(ret), errptr); - exit(1); -} - -// Install the trusted certificates. -ret = gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE, cred); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_credentials_set: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Associate the socket with the session object and set the server -// name. -gnutls_transport_set_ptr(session, (gnutls_transport_ptr_t)(uintptr_t)sockfd); -ret = gnutls_server_name_set(session, GNUTLS_NAME_DNS, - host, strlen(host)); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_server_name_set: %s\n", - gnutls_strerror(ret)); - exit(1); -} - -// Establish the session. -ret = gnutls_handshake(session); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_handshake: %s\n", - gnutls_strerror(ret)); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Credentials.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Credentials.xml deleted file mode 100644 index 6a5cd09..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Credentials.xml +++ /dev/null @@ -1,29 +0,0 @@ - - - - -// Load the trusted CA certificates. -gnutls_certificate_credentials_t cred = NULL; -int ret = gnutls_certificate_allocate_credentials (&cred); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_certificate_allocate_credentials: %s\n", - gnutls_strerror(ret)); - exit(1); -} -// gnutls_certificate_set_x509_system_trust needs GNUTLS version 3.0 -// or newer, so we hard-code the path to the certificate store -// instead. -static const char ca_bundle[] = "/etc/ssl/certs/ca-bundle.crt"; -ret = gnutls_certificate_set_x509_trust_file - (cred, ca_bundle, GNUTLS_X509_FMT_PEM); -if (ret == 0) { - fprintf(stderr, "error: no certificates found in: %s\n", ca_bundle); - exit(1); -} -if (ret < 0) { - fprintf(stderr, "error: gnutls_certificate_set_x509_trust_files(%s): %s\n", - ca_bundle, gnutls_strerror(ret)); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Match.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Match.xml deleted file mode 100644 index c4a51ce..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Match.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - -// Match the peer certificate against the host name. -// We can only obtain a set of DER-encoded certificates from the -// session object, so we have to re-parse the peer certificate into -// a certificate object. -gnutls_x509_crt_t cert; -ret = gnutls_x509_crt_init(&cert); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_x509_crt_init: %s\n", - gnutls_strerror(ret)); - exit(1); -} -// The peer certificate is the first certificate in the list. -ret = gnutls_x509_crt_import(cert, certs, GNUTLS_X509_FMT_DER); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_x509_crt_import: %s\n", - gnutls_strerror(ret)); - exit(1); -} -ret = gnutls_x509_crt_check_hostname(cert, host); -if (ret == 0 && !certificate_host_name_override(certs[0], host)) { - fprintf(stderr, "error: host name does not match certificate\n"); - exit(1); -} -gnutls_x509_crt_deinit(cert); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Verify.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Verify.xml deleted file mode 100644 index a3c9365..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-GNUTLS-Verify.xml +++ /dev/null @@ -1,42 +0,0 @@ - - - - -// Obtain the server certificate chain. The server certificate -// itself is stored in the first element of the array. -unsigned certslen = 0; -const gnutls_datum_t *const certs = - gnutls_certificate_get_peers(session, &certslen); -if (certs == NULL || certslen == 0) { - fprintf(stderr, "error: could not obtain peer certificate\n"); - exit(1); -} - -// Validate the certificate chain. -unsigned status = (unsigned)-1; -ret = gnutls_certificate_verify_peers2(session, &status); -if (ret != GNUTLS_E_SUCCESS) { - fprintf(stderr, "error: gnutls_certificate_verify_peers2: %s\n", - gnutls_strerror(ret)); - exit(1); -} -if (status != 0 && !certificate_validity_override(certs[0])) { - gnutls_datum_t msg; -#if GNUTLS_VERSION_AT_LEAST_3_1_4 - int type = gnutls_certificate_type_get (session); - ret = gnutls_certificate_verification_status_print(status, type, &out, 0); -#else - ret = -1; -#endif - if (ret == 0) { - fprintf(stderr, "error: %s\n", msg.data); - gnutls_free(msg.data); - exit(1); - } else { - fprintf(stderr, "error: certificate validation failed with code 0x%x\n", - status); - exit(1); - } -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-NSS-Close.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-NSS-Close.xml deleted file mode 100644 index 456e209..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-NSS-Close.xml +++ /dev/null @@ -1,15 +0,0 @@ - - - - -// Send close_notify alert. -if (PR_Shutdown(nspr, PR_SHUTDOWN_BOTH) != PR_SUCCESS) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Read error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -// Closes the underlying POSIX file descriptor, too. -PR_Close(nspr); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-NSS-Connect.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-NSS-Connect.xml deleted file mode 100644 index 692ad04..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-NSS-Connect.xml +++ /dev/null @@ -1,106 +0,0 @@ - - - - -// Wrap the POSIX file descriptor. This is an internal NSPR -// function, but it is very unlikely to change. -PRFileDesc* nspr = PR_ImportTCPSocket(sockfd); -sockfd = -1; // Has been taken over by NSPR. - -// Add the SSL layer. -{ - PRFileDesc *model = PR_NewTCPSocket(); - PRFileDesc *newfd = SSL_ImportFD(NULL, model); - if (newfd == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - model = newfd; - newfd = NULL; - if (SSL_OptionSet(model, SSL_ENABLE_SSL2, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_ENABLE_SSL2 error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - if (SSL_OptionSet(model, SSL_V2_COMPATIBLE_HELLO, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_V2_COMPATIBLE_HELLO error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - if (SSL_OptionSet(model, SSL_ENABLE_DEFLATE, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: set SSL_ENABLE_DEFLATE error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - - // Disable all ciphers (except RC4-based ciphers, for backwards - // compatibility). - const PRUint16 *const ciphers = SSL_GetImplementedCiphers(); - for (unsigned i = 0; i < SSL_GetNumImplementedCiphers(); i++) { - if (ciphers[i] != SSL_RSA_WITH_RC4_128_SHA - && ciphers[i] != SSL_RSA_WITH_RC4_128_MD5) { - if (SSL_CipherPrefSet(model, ciphers[i], PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: disable cipher %u: error %d: %s\n", - (unsigned)ciphers[i], err, PR_ErrorToName(err)); - exit(1); - } - } - } - - // Enable the strong ciphers. - for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL; - ++p) { - if (SSL_CipherPrefSet(model, *p, PR_TRUE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: enable cipher %u: error %d: %s\n", - (unsigned)*p, err, PR_ErrorToName(err)); - exit(1); - } - } - - // Allow overriding invalid certificate. - if (SSL_BadCertHook(model, bad_certificate, (char *)host) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_BadCertHook error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - - newfd = SSL_ImportFD(model, nspr); - if (newfd == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ImportFD error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } - nspr = newfd; - PR_Close(model); -} - -// Perform the handshake. -if (SSL_ResetHandshake(nspr, PR_FALSE) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ResetHandshake error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -if (SSL_SetURL(nspr, host) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_SetURL error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -if (SSL_ForceHandshake(nspr) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: SSL_ForceHandshake error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Connect.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Connect.xml deleted file mode 100644 index 40cc623..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Connect.xml +++ /dev/null @@ -1,26 +0,0 @@ - - - - -// Create the socket and connect it at the TCP layer. -SSLSocket socket = (SSLSocket) ctx.getSocketFactory() - .createSocket(host, port); - -// Disable the Nagle algorithm. -socket.setTcpNoDelay(true); - -// Adjust ciphers and protocols. -socket.setSSLParameters(params); - -// Perform the handshake. -socket.startHandshake(); - -// Validate the host name. The match() method throws -// CertificateException on failure. -X509Certificate peer = (X509Certificate) - socket.getSession().getPeerCertificates()[0]; -// This is the only way to perform host name checking on OpenJDK 6. -HostnameChecker.getInstance(HostnameChecker.TYPE_TLS).match( - host, peer); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Context.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Context.xml deleted file mode 100644 index b7fde16..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Context.xml +++ /dev/null @@ -1,26 +0,0 @@ - - - - -// Create the context. Specify the SunJSSE provider to avoid -// picking up third-party providers. Try the TLS 1.2 provider -// first, then fall back to TLS 1.0. -SSLContext ctx; -try { - ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); -} catch (NoSuchAlgorithmException e) { - try { - ctx = SSLContext.getInstance("TLSv1", "SunJSSE"); - } catch (NoSuchAlgorithmException e1) { - // The TLS 1.0 provider should always be available. - throw new AssertionError(e1); - } catch (NoSuchProviderException e1) { - throw new AssertionError(e1); - } -} catch (NoSuchProviderException e) { - // The SunJSSE provider should always be available. - throw new AssertionError(e); -} -ctx.init(null, null, null); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Context_For_Cert.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Context_For_Cert.xml deleted file mode 100644 index 6004157..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Context_For_Cert.xml +++ /dev/null @@ -1,22 +0,0 @@ - - - - -SSLContext ctx; -try { - ctx = SSLContext.getInstance("TLSv1.2", "SunJSSE"); -} catch (NoSuchAlgorithmException e) { - try { - ctx = SSLContext.getInstance("TLSv1", "SunJSSE"); - } catch (NoSuchAlgorithmException e1) { - throw new AssertionError(e1); - } catch (NoSuchProviderException e1) { - throw new AssertionError(e1); - } -} catch (NoSuchProviderException e) { - throw new AssertionError(e); -} -MyTrustManager tm = new MyTrustManager(certHash); -ctx.init(null, new TrustManager[] {tm}, null); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Hostname.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Hostname.xml deleted file mode 100644 index 586cb7b..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Hostname.xml +++ /dev/null @@ -1,7 +0,0 @@ - - - - -params.setEndpointIdentificationAlgorithm("HTTPS"); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Import.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Import.xml deleted file mode 100644 index 57c9343..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Import.xml +++ /dev/null @@ -1,18 +0,0 @@ - - - - -import java.security.NoSuchAlgorithmException; -import java.security.NoSuchProviderException; -import java.security.cert.CertificateEncodingException; -import java.security.cert.CertificateException; -import java.security.cert.X509Certificate; -import javax.net.ssl.SSLContext; -import javax.net.ssl.SSLParameters; -import javax.net.ssl.SSLSocket; -import javax.net.ssl.TrustManager; -import javax.net.ssl.X509TrustManager; - -import sun.security.util.HostnameChecker; - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-MyTrustManager.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-MyTrustManager.xml deleted file mode 100644 index 43fd12b..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-MyTrustManager.xml +++ /dev/null @@ -1,38 +0,0 @@ - - - - -public class MyTrustManager implements X509TrustManager { - private final byte[] certHash; - - public MyTrustManager(byte[] certHash) throws Exception { - this.certHash = certHash; - } - - @Override - public void checkClientTrusted(X509Certificate[] chain, String authType) - throws CertificateException { - throw new UnsupportedOperationException(); - } - - @Override - public void checkServerTrusted(X509Certificate[] chain, - String authType) throws CertificateException { - byte[] digest = getCertificateDigest(chain[0]); - String digestHex = formatHex(digest); - - if (Arrays.equals(digest, certHash)) { - System.err.println("info: accepting certificate: " + digestHex); - } else { - throw new CertificateException("certificate rejected: " + - digestHex); - } - } - - @Override - public X509Certificate[] getAcceptedIssuers() { - return new X509Certificate[0]; - } -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Use.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Use.xml deleted file mode 100644 index 11d708a..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenJDK-Use.xml +++ /dev/null @@ -1,11 +0,0 @@ - - - - -socket.getOutputStream().write("GET / HTTP/1.0\r\n\r\n" - .getBytes(Charset.forName("UTF-8"))); -byte[] buffer = new byte[4096]; -int count = socket.getInputStream().read(buffer); -System.out.write(buffer, 0, count); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-CTX.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-CTX.xml deleted file mode 100644 index 05e2854..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-CTX.xml +++ /dev/null @@ -1,71 +0,0 @@ - - - - -// Configure a client connection context. Send a hendshake for the -// highest supported TLS version, and disable compression. -const SSL_METHOD *const req_method = SSLv23_client_method(); -SSL_CTX *const ctx = SSL_CTX_new(req_method); -if (ctx == NULL) { - ERR_print_errors(bio_err); - exit(1); -} -SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_COMPRESSION); - -// Adjust the ciphers list based on a whitelist. First enable all -// ciphers of at least medium strength, to get the list which is -// compiled into OpenSSL. -if (SSL_CTX_set_cipher_list(ctx, "HIGH:MEDIUM") != 1) { - ERR_print_errors(bio_err); - exit(1); -} -{ - // Create a dummy SSL session to obtain the cipher list. - SSL *ssl = SSL_new(ctx); - if (ssl == NULL) { - ERR_print_errors(bio_err); - exit(1); - } - STACK_OF(SSL_CIPHER) *active_ciphers = SSL_get_ciphers(ssl); - if (active_ciphers == NULL) { - ERR_print_errors(bio_err); - exit(1); - } - // Whitelist of candidate ciphers. - static const char *const candidates[] = { - "AES128-GCM-SHA256", "AES128-SHA256", "AES256-SHA256", // strong ciphers - "AES128-SHA", "AES256-SHA", // strong ciphers, also in older versions - "RC4-SHA", "RC4-MD5", // backwards compatibility, supposed to be weak - "DES-CBC3-SHA", "DES-CBC3-MD5", // more backwards compatibility - NULL - }; - // Actually selected ciphers. - char ciphers[300]; - ciphers[0] = '\0'; - for (const char *const *c = candidates; *c; ++c) { - for (int i = 0; i < sk_SSL_CIPHER_num(active_ciphers); ++i) { - if (strcmp(SSL_CIPHER_get_name(sk_SSL_CIPHER_value(active_ciphers, i)), - *c) == 0) { - if (*ciphers) { - strcat(ciphers, ":"); - } - strcat(ciphers, *c); - break; - } - } - } - SSL_free(ssl); - // Apply final cipher list. - if (SSL_CTX_set_cipher_list(ctx, ciphers) != 1) { - ERR_print_errors(bio_err); - exit(1); - } -} - -// Load the set of trusted root certificates. -if (!SSL_CTX_set_default_verify_paths(ctx)) { - ERR_print_errors(bio_err); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Connect.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Connect.xml deleted file mode 100644 index 5cd433d..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Connect.xml +++ /dev/null @@ -1,55 +0,0 @@ - - - - -// Create the connection object. -SSL *ssl = SSL_new(ctx); -if (ssl == NULL) { - ERR_print_errors(bio_err); - exit(1); -} -SSL_set_fd(ssl, sockfd); - -// Enable the ServerNameIndication extension -if (!SSL_set_tlsext_host_name(ssl, host)) { - ERR_print_errors(bio_err); - exit(1); -} - -// Perform the TLS handshake with the server. -ret = SSL_connect(ssl); -if (ret != 1) { - // Error status can be 0 or negative. - ssl_print_error_and_exit(ssl, "SSL_connect", ret); -} - -// Obtain the server certificate. -X509 *peercert = SSL_get_peer_certificate(ssl); -if (peercert == NULL) { - fprintf(stderr, "peer certificate missing"); - exit(1); -} - -// Check the certificate verification result. Allow an explicit -// certificate validation override in case verification fails. -int verifystatus = SSL_get_verify_result(ssl); -if (verifystatus != X509_V_OK && !certificate_validity_override(peercert)) { - fprintf(stderr, "SSL_connect: verify result: %s\n", - X509_verify_cert_error_string(verifystatus)); - exit(1); -} - -// Check if the server certificate matches the host name used to -// establish the connection. -// FIXME: Currently needs OpenSSL 1.1. -if (X509_check_host(peercert, (const unsigned char *)host, strlen(host), - 0) != 1 - && !certificate_host_name_override(peercert, host)) { - fprintf(stderr, "SSL certificate does not match host name\n"); - exit(1); -} - -X509_free(peercert); - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Connection-Use.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Connection-Use.xml deleted file mode 100644 index ab54edf..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Connection-Use.xml +++ /dev/null @@ -1,15 +0,0 @@ - - - - -const char *const req = "GET / HTTP/1.0\r\n\r\n"; -if (SSL_write(ssl, req, strlen(req)) < 0) { - ssl_print_error_and_exit(ssl, "SSL_write", ret); -} -char buf[4096]; -ret = SSL_read(ssl, buf, sizeof(buf)); -if (ret < 0) { - ssl_print_error_and_exit(ssl, "SSL_read", ret); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Init.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Init.xml deleted file mode 100644 index 8211ce8..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-OpenSSL-Init.xml +++ /dev/null @@ -1,13 +0,0 @@ - - - - -// The following call prints an error message and calls exit() if -// the OpenSSL configuration file is unreadable. -OPENSSL_config(NULL); -// Provide human-readable error messages. -SSL_load_error_strings(); -// Register ciphers. -SSL_library_init(); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-Python-Connect.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-Python-Connect.xml deleted file mode 100644 index 0e98e87..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-Python-Connect.xml +++ /dev/null @@ -1,14 +0,0 @@ - - - - -sock = ssl.wrap_socket(sock, - ciphers="HIGH:-aNULL:-eNULL:-PSK:RC4-SHA:RC4-MD5", - ssl_version=ssl.PROTOCOL_TLSv1, - cert_reqs=ssl.CERT_REQUIRED, - ca_certs='/etc/ssl/certs/ca-bundle.crt') -# getpeercert() triggers the handshake as a side effect. -if not check_host_name(sock.getpeercert(), host): - raise IOError("peer certificate does not match host name") - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-Python-check_host_name.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-Python-check_host_name.xml deleted file mode 100644 index 3c325f8..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Client-Python-check_host_name.xml +++ /dev/null @@ -1,29 +0,0 @@ - - - - -def check_host_name(peercert, name): - """Simple certificate/host name checker. Returns True if the - certificate matches, False otherwise. Does not support - wildcards.""" - # Check that the peer has supplied a certificate. - # None/{} is not acceptable. - if not peercert: - return False - if peercert.has_key("subjectAltName"): - for typ, val in peercert["subjectAltName"]: - if typ == "DNS" and val == name: - return True - else: - # Only check the subject DN if there is no subject alternative - # name. - cn = None - for attr, val in peercert["subject"]: - # Use most-specific (last) commonName attribute. - if attr == "commonName": - cn = val - if cn is not None: - return cn == name - return False - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Credentials-Close.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Credentials-Close.xml deleted file mode 100644 index 8c28b0f..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Credentials-Close.xml +++ /dev/null @@ -1,7 +0,0 @@ - - - - -gnutls_certificate_free_credentials(cred); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Disconnect.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Disconnect.xml deleted file mode 100644 index b01464d..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Disconnect.xml +++ /dev/null @@ -1,14 +0,0 @@ - - - - -// Initiate an orderly connection shutdown. -ret = gnutls_bye(session, GNUTLS_SHUT_RDWR); -if (ret < 0) { - fprintf(stderr, "error: gnutls_bye: %s\n", gnutls_strerror(ret)); - exit(1); -} -// Free the session object. -gnutls_deinit(session); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Init.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Init.xml deleted file mode 100644 index 519522e..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Init.xml +++ /dev/null @@ -1,7 +0,0 @@ - - - - -gnutls_global_init(); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Use.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Use.xml deleted file mode 100644 index a6a3f9c..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-GNUTLS-Use.xml +++ /dev/null @@ -1,18 +0,0 @@ - - - - -char buf[4096]; -snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host); -ret = gnutls_record_send(session, buf, strlen(buf)); -if (ret < 0) { - fprintf(stderr, "error: gnutls_record_send: %s\n", gnutls_strerror(ret)); - exit(1); -} -ret = gnutls_record_recv(session, buf, sizeof(buf)); -if (ret < 0) { - fprintf(stderr, "error: gnutls_record_recv: %s\n", gnutls_strerror(ret)); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Close.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Close.xml deleted file mode 100644 index e34cea8..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Close.xml +++ /dev/null @@ -1,8 +0,0 @@ - - - - -SECMOD_DestroyModule(module); -NSS_ShutdownContext(ctx); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Includes.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Includes.xml deleted file mode 100644 index ee183d0..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Includes.xml +++ /dev/null @@ -1,20 +0,0 @@ - - - - -// NSPR include files -#include <prerror.h> -#include <prinit.h> - -// NSS include files -#include <nss.h> -#include <pk11pub.h> -#include <secmod.h> -#include <ssl.h> -#include <sslproto.h> - -// Private API, no other way to turn a POSIX file descriptor into an -// NSPR handle. -NSPR_API(PRFileDesc*) PR_ImportTCPSocket(int); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Init.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Init.xml deleted file mode 100644 index d56651b..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Init.xml +++ /dev/null @@ -1,63 +0,0 @@ - - - - -PR_Init(PR_USER_THREAD, PR_PRIORITY_NORMAL, 0); -NSSInitContext *const ctx = - NSS_InitContext("sql:/etc/pki/nssdb", "", "", "", NULL, - NSS_INIT_READONLY | NSS_INIT_PK11RELOAD); -if (ctx == NULL) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - -// Ciphers to enable. -static const PRUint16 good_ciphers[] = { - TLS_RSA_WITH_AES_128_CBC_SHA, - TLS_RSA_WITH_AES_256_CBC_SHA, - SSL_RSA_WITH_3DES_EDE_CBC_SHA, - SSL_NULL_WITH_NULL_NULL // sentinel -}; - -// Check if the current policy allows any strong ciphers. If it -// doesn't, switch to the "domestic" (unrestricted) policy. This is -// not thread-safe and has global impact. Consequently, we only do -// it if absolutely necessary. -int found_good_cipher = 0; -for (const PRUint16 *p = good_ciphers; *p != SSL_NULL_WITH_NULL_NULL; - ++p) { - PRInt32 policy; - if (SSL_CipherPolicyGet(*p, &policy) != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: policy for cipher %u: error %d: %s\n", - (unsigned)*p, err, PR_ErrorToName(err)); - exit(1); - } - if (policy == SSL_ALLOWED) { - fprintf(stderr, "info: found cipher %x\n", (unsigned)*p); - found_good_cipher = 1; - break; - } -} -if (!found_good_cipher) { - if (NSS_SetDomesticPolicy() != SECSuccess) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSS_SetDomesticPolicy: error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); - } -} - -// Initialize the trusted certificate store. -char module_name[] = "library=libnssckbi.so name=\"Root Certs\""; -SECMODModule *module = SECMOD_LoadUserModule(module_name, NULL, PR_FALSE); -if (module == NULL || !module->loaded) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: NSPR error code %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Use.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Use.xml deleted file mode 100644 index f1a0c6d..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-NSS-Use.xml +++ /dev/null @@ -1,22 +0,0 @@ - - - - -char buf[4096]; -snprintf(buf, sizeof(buf), "GET / HTTP/1.0\r\nHost: %s\r\n\r\n", host); -PRInt32 ret = PR_Write(nspr, buf, strlen(buf)); -if (ret < 0) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Write error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} -ret = PR_Read(nspr, buf, sizeof(buf)); -if (ret < 0) { - const PRErrorCode err = PR_GetError(); - fprintf(stderr, "error: PR_Read error %d: %s\n", - err, PR_ErrorToName(err)); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Nagle.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Nagle.xml deleted file mode 100644 index 824fab5..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Nagle.xml +++ /dev/null @@ -1,12 +0,0 @@ - - - - -const int val = 1; -int ret = setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &val, sizeof(val)); -if (ret < 0) { - perror("setsockopt(TCP_NODELAY)"); - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenJDK-Parameters.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenJDK-Parameters.xml deleted file mode 100644 index af48ca6..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenJDK-Parameters.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - -// Prepare TLS parameters. These have to applied to every TLS -// socket before the handshake is triggered. -SSLParameters params = ctx.getDefaultSSLParameters(); -// Do not send an SSL-2.0-compatible Client Hello. -ArrayList<String> protocols = new ArrayList<String>( - Arrays.asList(params.getProtocols())); -protocols.remove("SSLv2Hello"); -params.setProtocols(protocols.toArray(new String[protocols.size()])); -// Adjust the supported ciphers. -ArrayList<String> ciphers = new ArrayList<String>( - Arrays.asList(params.getCipherSuites())); -ciphers.retainAll(Arrays.asList( - "TLS_RSA_WITH_AES_128_CBC_SHA256", - "TLS_RSA_WITH_AES_256_CBC_SHA256", - "TLS_RSA_WITH_AES_256_CBC_SHA", - "TLS_RSA_WITH_AES_128_CBC_SHA", - "SSL_RSA_WITH_3DES_EDE_CBC_SHA", - "SSL_RSA_WITH_RC4_128_SHA1", - "SSL_RSA_WITH_RC4_128_MD5", - "TLS_EMPTY_RENEGOTIATION_INFO_SCSV")); -params.setCipherSuites(ciphers.toArray(new String[ciphers.size()])); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Connection-Close.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Connection-Close.xml deleted file mode 100644 index 0e446ef..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Connection-Close.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - -// Send the close_notify alert. -ret = SSL_shutdown(ssl); -switch (ret) { -case 1: - // A close_notify alert has already been received. - break; -case 0: - // Wait for the close_notify alert from the peer. - ret = SSL_shutdown(ssl); - switch (ret) { - case 0: - fprintf(stderr, "info: second SSL_shutdown returned zero\n"); - break; - case 1: - break; - default: - ssl_print_error_and_exit(ssl, "SSL_shutdown 2", ret); - } - break; -default: - ssl_print_error_and_exit(ssl, "SSL_shutdown 1", ret); -} -SSL_free(ssl); -close(sockfd); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Context-Close.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Context-Close.xml deleted file mode 100644 index 89a324e..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Context-Close.xml +++ /dev/null @@ -1,7 +0,0 @@ - - - - -SSL_CTX_free(ctx); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Errors.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Errors.xml deleted file mode 100644 index ab16ce7..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-OpenSSL-Errors.xml +++ /dev/null @@ -1,31 +0,0 @@ - - - - -static void __attribute__((noreturn)) -ssl_print_error_and_exit(SSL *ssl, const char *op, int ret) -{ - int subcode = SSL_get_error(ssl, ret); - switch (subcode) { - case SSL_ERROR_NONE: - fprintf(stderr, "error: %s: no error to report\n", op); - break; - case SSL_ERROR_WANT_READ: - case SSL_ERROR_WANT_WRITE: - case SSL_ERROR_WANT_X509_LOOKUP: - case SSL_ERROR_WANT_CONNECT: - case SSL_ERROR_WANT_ACCEPT: - fprintf(stderr, "error: %s: invalid blocking state %d\n", op, subcode); - break; - case SSL_ERROR_SSL: - fprintf(stderr, "error: %s: TLS layer problem\n", op); - case SSL_ERROR_SYSCALL: - fprintf(stderr, "error: %s: system call failed: %s\n", op, strerror(errno)); - break; - case SSL_ERROR_ZERO_RETURN: - fprintf(stderr, "error: %s: zero return\n", op); - } - exit(1); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Python-Close.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Python-Close.xml deleted file mode 100644 index fd20ff2..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Python-Close.xml +++ /dev/null @@ -1,7 +0,0 @@ - - - - -sock.close() - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Python-Use.xml b/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Python-Use.xml deleted file mode 100644 index 08690ca..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Features/snippets/TLS-Python-Use.xml +++ /dev/null @@ -1,8 +0,0 @@ - - - - -sock.write("GET / HTTP/1.1\r\nHost: " + host + "\r\n\r\n") -print sock.read() - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Python/Language.xml b/defensive-coding/tmp/en-US/xml_tmp/Python/Language.xml deleted file mode 100644 index 5cfec8f..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Python/Language.xml +++ /dev/null @@ -1,74 +0,0 @@ - - - - The Python Programming Language - - Python provides memory safety by default, so low-level security - vulnerabilities are rare and typically needs fixing the Python - interpreter or standard library itself. - - - Other sections with Python-specific advice include: - - - - - - - - - - - - - - - , in - particular - - - - - - - - -
- Dangerous standard library features - - Some areas of the standard library, notably the - ctypes module, do not provide memory safety - guarantees comparable to the rest of Python. If such - functionality is used, the advice in should be followed. - -
-
- Run-time compilation and code generation - - The following Python functions and statements related to code - execution should be avoided: - - - compile - eval - exec - execfile - - - If you need to parse integers or floating point values, use the - int and float - functions instead of eval. Sandboxing - untrusted Python code does not work reliably. - -
-
- Sandboxing - - The rexec Python module cannot safely sandbox - untrusted code and should not be used. The standard CPython - implementation is not suitable for sandboxing. - -
- diff --git a/defensive-coding/tmp/en-US/xml_tmp/Python/schemas.xml b/defensive-coding/tmp/en-US/xml_tmp/Python/schemas.xml deleted file mode 100644 index 8e84245..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Python/schemas.xml +++ /dev/null @@ -1,4 +0,0 @@ - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Revision_History.xml b/defensive-coding/tmp/en-US/xml_tmp/Revision_History.xml deleted file mode 100644 index c9f6483..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Revision_History.xml +++ /dev/null @@ -1,27 +0,0 @@ - - -%BOOK_ENTITIES; -]> - - Revision History - - - - 0-1 - Thu Mar 7 2013 - - Eric - Christensen - sparks@redhat.com - - - - Initial publication. - - - - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Cryptography.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/Cryptography.xml deleted file mode 100644 index 88f14a3..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Cryptography.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - - Cryptography - -
- Primitives - - Chosing from the following cryptographic primitives is - recommended: - - - RSA with 2048 bit keys and OAEP - AES-128 in CBC mode - SHA-256 - HMAC-SHA-256 - HMAC-SHA-1 - - - Other cryptographic algorithms can be used if they are required - for interoperability with existing software: - - - RSA with key sizes larger than 1024 - and legacy padding - AES-192 - AES-256 - 3DES (triple DES, with two or three 56 bit keys) - RC4 (but very, very strongly discouraged) - SHA-1 - HMAC-MD5 - - - Important - - These primitives are difficult to use in a secure way. Custom - implementation of security protocols should be avoided. For - protecting confidentiality and integrity of network - transmissions, TLS should be used (). - - - -
- -
- Randomness - - The following facilities can be used to generate unpredictable - and non-repeating values. When these functions are used without - special safeguards, each individual rnadom value should be at - least 12 bytes long. - - - - PK11_GenerateRandom in the NSS library - (usable for high data rates) - - - RAND_bytes in the OpenSSL library - (usable for high data rates) - - - gnutls_rnd in GNUTLS, with - GNUTLS_RND_RANDOM as the first argument - (usable for high data rates) - - - java.security.SecureRandom in Java - (usable for high data rates) - - - os.urandom in Python - - - Reading from the /dev/urandom - character device - - - - All these functions should be non-blocking, and they should not - wait until physical randomness becomes available. (Some - cryptography providers for Java can cause - java.security.SecureRandom to block, however.) - Those functions which do not obtain all bits directly from - /dev/urandom are suitable for high data - rates because they do not deplete the system-wide entropy pool. - - - Difficult to use API - - Both RAND_bytes and - PK11_GenerateRandom have three-state - return values (with conflicting meanings). Careful error - checking is required. Please review the documentation when - using these functions. - - - - Other sources of randomness should be considered predictable. - - - Generating randomness for cryptographic keys in long-term use - may need different steps and is best left to cryptographic - libraries. - -
- - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Descriptors.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/Descriptors.xml deleted file mode 100644 index bdf1fb2..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Descriptors.xml +++ /dev/null @@ -1,266 +0,0 @@ - - - - File Descriptor Management - - File descriptors underlie all input/output mechanisms offered by - the system. They are used to implementation the FILE - *-based functions found in - <stdio.h>, and all the file and network - communication facilities provided by the Python and Java - environments are eventually implemented in them. - - - File descriptors are small, non-negative integers in userspace, - and are backed on the kernel side with complicated data structures - which can sometimes grow very large. - -
- Closing descriptors - - If a descriptor is no longer used by a program and is not closed - explicitly, its number cannot be reused (which is problematic in - itself, see ), and - the kernel resources are not freed. Therefore, it is important - to close all descriptors at the earlierst point in time - possible, but not earlier. - -
- Error handling during descriptor close - - The close system call is always - successful in the sense that the passed file descriptor is - never valid after the function has been called. However, - close still can return an error, for - example if there was a file system failure. But this error is - not very useful because the absence of an error does not mean - that all caches have been emptied and previous writes have - been made durable. Programs which need such guarantees must - open files with O_SYNC or use - fsync or fdatasync, and - may also have to fsync the directory - containing the file. - -
-
- Closing descriptors and race conditions - - Unlike process IDs, which are recycle only gradually, the - kernel always allocates the lowest unused file descriptor when - a new descriptor is created. This means that in a - multi-threaded program which constantly opens and closes file - descriptors, descriptors are reused very quickly. Unless - descriptor closing and other operations on the same file - descriptor are synchronized (typically, using a mutex), there - will be race coniditons and I/O operations will be applied to - the wrong file descriptor. - - - Sometimes, it is necessary to close a file descriptor - concurrently, while another thread might be about to use it in - a system call. In order to support this, a program needs to - create a single special file descriptor, one on which all I/O - operations fail. One way to achieve this is to use - socketpair, close one of the descriptors, - and call shutdown(fd, SHUTRDWR) on the - other. - - - When a descriptor is closed concurrently, the program does not - call close on the descriptor. Instead it - program uses dup2 to replace the - descriptor to be closed with the dummy descriptor created - earlier. This way, the kernel will not reuse the descriptor, - but it will carry out all other steps associated with calling - a descriptor (for instance, if the descriptor refers to a - stream socket, the peer will be notified). - - - This is just a sketch, and many details are missing. - Additional data structures are needed to determine when it is - safe to really close the descriptor, and proper locking is - required for that. - -
-
- Lingering state after close - - By default, closing a stream socket returns immediately, and - the kernel will try to send the data in the background. This - means that it is impossible to implement accurate accounting - of network-related resource utilization from userspace. - - - The SO_LINGER socket option alters the - behavior of close, so that it will return - only after the lingering data has been processed, either by - sending it to the peer successfully, or by discarding it after - the configured timeout. However, there is no interface which - could perform this operation in the background, so a separate - userspace thread is needed for each close - call, causing scalability issues. - - - Currently, there is no application-level countermeasure which - applies universally. Mitigation is possible with - iptables (the - connlimit match type in particular) and - specialized filtering devices for denial-of-service network - traffic. - - - These problems are not related to the - TIME_WAIT state commonly seen in - netstat output. The kernel - automatically expires such sockets if necessary. - -
-
- -
- Preventing file descriptor leaks to child processes - - Child processes created with fork share - the initial set of file descriptors with their parent - process. By default, file descriptors are also preserved if - a new process image is created with execve - (or any of the other functions such as system - or posix_spawn). - - - Usually, this behavior is not desirable. There are two ways to - turn it off, that is, to prevent new process images from - inheriting the file descriptors in the parent process: - - - - - Set the close-on-exec flag on all newly created file - descriptors. Traditionally, this flag is controlled by the - FD_CLOEXEC flag, using - F_GETFD and F_SETFD - operations of the fcntl function. - - - However, in a multi-threaded process, there is a race - condition: a subprocess could have been created between the - time the descriptor was created and the - FD_CLOEXEC was set. Therefore, many system - calls which create descriptors (such as - open and openat) - now accept the O_CLOEXEC flag - (SOCK_CLOEXEC for - socket and - socketpair), which cause the - FD_CLOEXEC flag to be set for the file - descriptor in an atomic fashion. In addition, a few new - systems calls were introduced, such as - pipe2 and dup3. - - - The downside of this approach is that every descriptor needs - to receive special treatment at the time of creation, - otherwise it is not completely effective. - - - - - After calling fork, but before creating - a new process image with execve, all - file descriptors which the child process will not need are - closed. - - - Traditionally, this was implemented as a loop over file - descriptors ranging from 3 to - 255 and later 1023. - But this is only an approximatio because it is possible to - create file descriptors outside this range easily (see ). - Another approach reads /proc/self/fd - and closes the unexpected descriptors listed there, but this - approach is much slower. - - - - - At present, environments which care about file descriptor - leakage implement the second approach. OpenJDK 6 and 7 - are among them. - -
- -
- Dealing with the <function>select</function> limit - - By default, a user is allowed to open only 1024 files in a - single process, but the system administrator can easily change - this limit (which is necessary for busy network servers). - However, there is another restriction which is more difficult to - overcome. - - - The select function only supports a - maximum of FD_SETSIZE file descriptors - (that is, the maximum permitted value for a file descriptor - is FD_SETSIZE - 1, usually 1023.) If a - process opens many files, descriptors may exceed such - limits. It is impossible to query such descriptors using - select. - - - If a library which creates many file descriptors is used in - the same process as a library which uses - select, at least one of them needs to - be changed. - Calls to select can be replaced with - calls to poll or another event handling - mechanism. - - - Alternatively, the library with high descriptor usage can - relocate descriptors above the FD_SETSIZE - limit using the following procedure. - - - - - Create the file descriptor fd as - usual, preferably with the O_CLOEXEC - flag. - - - - - Before doing anything else with the descriptor - fd, invoke: - - - int newfd = fcntl(fd, F_DUPFD_CLOEXEC, (long)FD_SETSIZE); - - - - - Check that newfd result is - non-negative, otherwise close fd and - report an error, and return. - - - - - Close fd and continue to use - newfd. - - - - - The new descriptor has been allocated above the - FD_SETSIZE. Even though this algorithm - is racy in the sense that the FD_SETSIZE - first descriptors could fill up, a very high degree of - physical parallelism is required before this becomes a problem. - -
- diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/File_System.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/File_System.xml deleted file mode 100644 index ee3eb17..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/File_System.xml +++ /dev/null @@ -1,339 +0,0 @@ - - - - File system manipulation - - In this chapter, we discuss general file system manipulation, with - a focus on access files and directories to which an other, - potentially untrusted user has write access. - - - Temporary files are covered in their own chapter, . - -
- Working with files and directories owned by other users - - Sometimes, it is necessary to operate on files and directories - owned by other (potentially untrusted) users. For example, a - system administrator could remove the home directory of a user, - or a package manager could update a file in a directory which is - owned by an application-specific user. This differs from - accessing the file system as a specific user; see - . - - - Accessing files across trust boundaries faces several - challenges, particularly if an entire directory tree is being - traversed: - - - - - Another user might add file names to a writable directory at - any time. This can interfere with file creation and the - order of names returned by readdir. - - - - - Merely opening and closing a file can have side effects. - For instance, an automounter can be triggered, or a tape - device rewound. Opening a file on a local file system can - block indefinitely, due to mandatory file locking, unless - the O_NONBLOCK flag is specified. - - - - - Hard links and symbolic links can redirect the effect of - file system operations in unexpected ways. The - O_NOFOLLOW and - AT_SYMLINK_NOFOLLOW variants of system - calls only affected final path name component. - - - - - The structure of a directory tree can change. For example, - the parent directory of what used to be a subdirectory - within the directory tree being processed could suddenly - point outside that directory tree. - - - - - Files should always be created with the - O_CREAT and O_EXCL flags, - so that creating the file will fail if it already exists. This - guards against the unexpected appearance of file names, either - due to creation of a new file, or hard-linking of an existing - file. In multi-threaded programs, rather than manipulating the - umask, create the files with mode 000 if - possible, and adjust it afterwards with - fchmod. - - - To avoid issues related to symbolic links and directory tree - restructuring, the “at” variants of system - calls have to be used (that is, functions like - openat, fchownat, - fchmodat, and - unlinkat, together with - O_NOFOLLOW or - AT_SYMLINK_NOFOLLOW). Path names passed to - these functions must have just a single component (that is, - without a slash). When descending, the descriptors of parent - directories must be kept open. The missing - opendirat function can be emulated with - openat (with an - O_DIRECTORY flag, to avoid opening special - files with side effects), followed by - fdopendir. - - - If the “at” functions are not available, it - is possible to emulate them by changing the current directory. - (Obviously, this only works if the process is not multi-threaded.) - fchdir has to be used to change the current - directory, and the descriptors of the parent directories have to - be kept open, just as with the “at”-based - approach. chdir("...") is unsafe because it - might ascend outside the intended directory tree. - - - This “at” function emulation is currently - required when manipulating extended attributes. In this case, - the lsetxattr function can be used, with a - relative path name consisting of a single component. This also - applies to SELinux contexts and the - lsetfilecon function. - - - Currently, it is not possible to avoid opening special files - and changes to files with hard links if the - directory containing them is owned by an untrusted user. - (Device nodes can be hard-linked, just as regular files.) - fchmodat and fchownat - affect files whose link count is greater than one. But opening - the files, checking that the link count is one with - fstat, and using - fchmod and fchown on - the file descriptor may have unwanted side effects, due to item - 2 above. When creating directories, it is therefore important - to change the ownership and permissions only after it has been - fully created. Until that point, file names are stable, and no - files with unexpected hard links can be introduced. - - - Similarly, when just reading a directory owned by an untrusted - user, it is currently impossible to reliably avoid opening - special files. - - - There is no workaround against the instability of the file list - returned by readdir. Concurrent - modification of the directory can result in a list of files - being returned which never actually existed on disk. - - - Hard links and symbolic links can be safely deleted using - unlinkat without further checks because - deletion only affects the name within the directory tree being - processed. - -
-
- Accessing the file system as a different user - - This section deals with access to the file system as a specific - user. This is different from accessing files and directories owned by a - different, potentially untrusted user; see . - - - One approach is to spawn a child process which runs under the - target user and group IDs (both effective and real IDs). Note - that this child process can block indefinitely, even when - processing regular files only. For example, a special FUSE file - system could cause the process to hang in uninterruptible sleep - inside a stat system call. - - - An existing process could change its user and group ID using - setfsuid and setfsgid. - (These functions are preferred over seteuid - and setegid because they do not allow the - impersonated user to send signals to the process.) These - functions are not thread safe. In multi-threaded processes, - these operations need to be performed in a single-threaded child - process. Unexpected blocking may occur as well. - - - It is not recommended to try to reimplement the kernel - permission checks in user space because the required checks are - complex. It is also very difficult to avoid race conditions - during path name resolution. - -
-
- File system limits - - For historical reasons, there are preprocessor constants such as - PATH_MAX, NAME_MAX. - However, on most systems, the length of canonical path names - (absolute path names with all symbolic links resolved, as - returned by realpath or - canonicalize_file_name) can exceed - PATH_MAX bytes, and individual file name - components can be longer than NAME_MAX. This - is also true of the _PC_PATH_MAX and - _PC_NAME_MAX values returned by - pathconf, and the - f_namemax member of struct - statvfs. Therefore, these constants should not be - used. This is also reason why the - readdir_r should never be used (instead, - use readdir). - - - You should not write code in a way that assumes that there is an - upper limit on the number of subdirectories of a directory, the - number of regular files in a directory, or the link count of an - inode. - -
-
- File system features - - Not all file systems support all features. This makes it very - difficult to write general-purpose tools for copying files. For - example, a copy operation intending to preserve file permissions - will generally fail when copying to a FAT file system. - - - - - Some file systems are case-insensitive. Most should be - case-preserving, though. - - - - - Name length limits vary greatly, from eight to thousands of - bytes. Path length limits differ as well. Most systems - impose an upper bound on path names passed to the kernel, - but using relative path names, it is possible to create and - access files whose absolute path name is essentially of - unbounded length. - - - - - Some file systems do not store names as fairly unrestricted - byte sequences, as it has been traditionally the case on GNU - systems. This means that some byte sequences (outside the - POSIX safe character set) are not valid names. Conversely, - names of existing files may not be representable as byte - sequences, and the files are thus inaccessible on GNU - systems. Some file systems perform Unicode canonicalization - on file names. These file systems preserve case, but - reading the name of a just-created file using - readdir might still result in a - different byte sequence. - - - - - Permissions and owners are not universally supported (and - SUID/SGID bits may not be available). For example, FAT file - systems assign ownership based on a mount option, and - generally mark all files as executable. Any attempt to - change permissions would result in an error. - - - - - Non-regular files (device nodes, FIFOs) are not generally - available. - - - - - Only on some file systems, files can have holes, that is, - not all of their contents is backed by disk storage. - - - - - ioctl support (even fairly generic - functionality such as FIEMAP for - discovering physical file layout and holes) is - file-system-specific. - - - - - Not all file systems support extended attributes, ACLs and - SELinux metadata. Size and naming restriction on extended - attributes vary. - - - - - Hard links may not be supported at all (FAT) or only within - the same directory (AFS). Symbolic links may not be - available, either. Reflinks (hard links with copy-on-write - semantics) are still very rare. Recent systems restrict - creation of hard links to users which own the target file or - have read/write access to it, but older systems do not. - - - - - Renaming (or moving) files using rename - can fail (even when stat indicates that - the source and target directories are located on the same - file system). This system call should work if the old and - new paths are located in the same directory, though. - - - - - Locking semantics vary among file systems. This affects - advisory and mandatory locks. For example, some network - file systems do not allow deleting files which are opened by - any process. - - - - - Resolution of time stamps varies from two seconds to - nanoseconds. Not all time stamps are available on all file - systems. File creation time (birth - time) is not exposed over the - stat/fstat - interface, even if stored by the file system. - - - -
-
- Checking free space - - The statvfs and - fstatvfs functions allow programs to - examine the number of available blocks and inodes, through the - members f_bfree, f_bavail, - f_ffree, and f_favail of - struct statvfs. Some file systems return - fictional values in the f_ffree and - f_favail fields, so the only reliable way to - discover if the file system still has space for a file is to try - to create it. The f_bfree field should be - reasonably accurate, though. - -
- - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Library_Design.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/Library_Design.xml deleted file mode 100644 index 7c959ab..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Library_Design.xml +++ /dev/null @@ -1,195 +0,0 @@ - - - - Library Design - - Throught this section, the term client code - refers to applications and other libraries using the library. - - -
- State management - - -
- Global state - - Global state should be avoided. - - - If this is impossible, the global state must be protected with - a lock. For C/C++, you can use the - pthread_mutex_lock - and pthread_mutex_unlock - functions without linking against -lpthread - because the system provides stubs for non-threaded processes. - - - For compatibility with fork, these locks - should be acquired and released in helpers registered with - pthread_atfork. This function is not - available without -lpthread, so you need to - use dlsym or a weak symbol to obtain its - address. - - - If you need fork protection for other - reasons, you should store the process ID and compare it to the - value returned by getpid each time you - access the global state. (getpid is not - implemented as a system call and is fast.) If the value - changes, you know that you have to re-create the state object. - (This needs to be combined with locking, of course.) - -
-
- Handles - - Library state should be kept behind a curtain. Client code - should receive only a handle. In C, the handle can be a - pointer to an incomplete struct. In C++, - the handle can be a pointer to an abstract base class, or it - can be hidden using the pointer-to-implementation idiom. - - - The library should provide functions for creating and - destroying handles. (In C++, it is possible to use virtual - destructors for the latter.) Consistency between creation and - destruction of handles is strongly recommended: If the client - code created a handle, it is the responsibility of the client - code to destroy it. (This is not always possible or - convenient, so sometimes, a transfer of ownership has to - happen.) - - - Using handles ensures that it is possible to change the way - the library represents state in a way that is transparent to - client code. This is important to facilitate security updates - and many other code changes. - - - It is not always necessary to protect state behind a handle - with a lock. This depends on the level of thread safety - the library provides. - -
-
- -
- Object orientation - - Classes should be either designed as base classes, or it should - be impossible to use them as base classes (like - final classes in Java). Classes which are - not designed for inheritance and are used as base classes - nevertheless create potential maintenance hazards because it is - difficult to predict how client code will react when calls to - virtual methods are added, reordered or removed. - - - Virtual member functions can be used as callbacks. See - - for some of the challenges involved. - -
- -
- Callbacks - - Higher-order code is difficult to analyze for humans and - computers alike, so it should be avoided. Often, an - iterator-based interface (a library function which is called - repeatedly by client code and returns a stream of events) leads - to a better design which is easier to document and use. - - - If callbacks are unavoidable, some guidelines for them follow. - - - In modern C++ code, std::function objects - should be used for callbacks. - - - In older C++ code and in C code, all callbacks must have an - additional closure parameter of type void *, - the value of which can be specified by client code. If - possible, the value of the closure parameter should be provided - by client code at the same time a specific callback is - registered (or specified as a function argument). If a single - closure parameter is shared by multiple callbacks, flexibility - is greatly reduced, and conflicts between different pieces of - client code using the same library object could be unresolvable. - In some cases, it makes sense to provide a de-registration - callback which can be used to destroy the closure parameter when - the callback is no longer used. - - - Callbacks can throw exceptions or call - longjmp. If possible, all library objects - should remain in a valid state. (All further operations on them - can fail, but it should be possible to deallocate them without - causing resource leaks.) - - - The presence of callbacks raises the question if functions - provided by the library are reentrant. - Unless a library was designed for such use, bad things will - happen if a callback function uses functions in the same library - (particularly if they are invoked on the same objects and - manipulate the same state). When the callback is invoked, the - library can be in an inconsistent state. Reentrant functions - are more difficult to write than thread-safe functions (by - definition, simple locking would immediately lead to deadlocks). - It is also difficult to decide what to do when destruction of an - object which is currently processing a callback is requested. - -
- -
- Process attributes - - Several attributes are global and affect all code in the - process, not just the library that manipulates them. - - - - environment variables - (see ) - - - umask - - - user IDs, group IDs and capabilities - - - current working directory - - - signal handlers, signal masks and signal delivery - - - file locks (especially fcntl locks - behave in surprising ways, not just in a multi-threaded - environment) - - - - Library code should avoid manipulating these global process - attributes. It should not rely on environment variables, umask, - the current working directory and signal masks because these - attributes can be inherted from an untrusted source. - - - In addition, there are obvious process-wide aspects such as the - virtual memory layout, the set of open files and dynamic shared - objects, but with the exception of shared objects, these can be - manipulated in a relatively isolated way. - - -
- - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Locking.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/Locking.xml deleted file mode 100644 index f85e61e..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Locking.xml +++ /dev/null @@ -1,5 +0,0 @@ - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Processes.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/Processes.xml deleted file mode 100644 index 90f01f0..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Processes.xml +++ /dev/null @@ -1,483 +0,0 @@ - - - - Processes - -
- Safe process creation - - This section describes how to create new child processes in a - safe manner. In addition to the concerns addressed below, there - is the possibility of file descriptor leaks, see . - -
- Obtaining the program path and the command line - template - - The name and path to the program being invoked should be - hard-coded or controlled by a static configuration file stored - at a fixed location (at an file system absolute path). The - same applies to the template for generating the command line. - - - The configured program name should be an absolute path. If it - is a relative path, the contents of the PATH - must be obtained in s secure manner (see ). - If the PATH variable is not set or untrusted, - the safe default /bin:/usr/bin must be - used. - - - If too much flexibility is provided here, it may allow - invocation of arbitrary programs without proper authorization. - -
- -
- Bypassing the shell - - Child processes should be created without involving the system - shell. - - - For C/C++, system should not be used. - The posix_spawn function can be used - instead, or a combination fork and - execve. (In some cases, it may be - preferable to use vfork or the - Linux-specific clone system call instead - of fork.) - - - In Python, the subprocess module bypasses - the shell by default (when the shell - keyword argument is not set to true). - os.system should not be used. - - - The Java class java.lang.ProcessBuilder can be - used to create subprocesses without interference from the - system shell. - - - Portability notice - - On Windows, there is no argument vector, only a single - argument string. Each application is responsible for parsing - this string into an argument vector. There is considerable - variance among the quoting style recognized by applications. - Some of them expand shell wildcards, others do not. Extensive - application-specific testing is required to make this secure. - - - - Note that some common applications (notably - ssh) unconditionally introduce the - use of a shell, even if invoked directly without a shell. It is - difficult to use these applications in a secure manner. In this - case, untrusted data should be supplied by other means. For - example, standard input could be used, instead of the command - line. - -
- -
- Specifying the process environment - - Child processes should be created with a minimal set of - environment variables. This is absolutely essential if there - is a trust transition involved, either when the parent process - was created, or during the creation of the child process. - - - In C/C++, the environment should be constructed as an array of - strings and passed as the envp argument to - posix_spawn or execve. - The functions setenv, - unsetenv and putenv - should not be used. They are not thread-safe and suffer from - memory leaks. - - - Python programs need to specify a dict for - the the env argument of the - subprocess.Popen constructor. - The Java class java.lang.ProcessBuilder - provides a environment() method, - which returns a map that can be manipulated. - - - The following list provides guidelines for selecting the set - of environment variables passed to the child process. - - - - - PATH should be initialized to - /bin:/usr/bin. - - - - - USER and HOME can be inhereted - from the parent process environment, or they can be - initialized from the pwent structure - for the user. - - - - The DISPLAY and XAUTHORITY - variables should be passed to the subprocess if it is an X - program. Note that this will typically not work across trust - boundaries because XAUTHORITY refers to a file - with 0600 permissions. - - - - - The location-related environment variables - LANG, LANGUAGE, - LC_ADDRESS, LC_ALL, - LC_COLLATE, LC_CTYPE, - LC_IDENTIFICATION, - LC_MEASUREMENT, LC_MESSAGES, - LC_MONETARY, LC_NAME, - LC_NUMERIC, LC_PAPER, - LC_TELEPHONE and LC_TIME - can be passed to the subprocess if present. - - - - - The called process may need application-specific - environment variables, for example for passing passwords. - (See .) - - - - - All other environment variables should be dropped. Names - for new environment variables should not be accepted from - untrusted sources. - - - -
- -
- Robust argument list processing - - When invoking a program, it is sometimes necessary to include - data from untrusted sources. Such data should be check - against embedded NUL characters because the - system APIs will sliently truncate argument strings at the first - NUL character. - - - The following recommendations assume that the program being - invoked uses GNU-style option processing using - getopt_long. This convention is widely - used, but it is just that, and individual programs might - interpret a command line in a different way. - - - If the untrusted data has to go into an option, use the - --option-name=VALUE syntax, placing the - option and its value into the same command line argument. - This avoids any potential confusion if the data starts with - -. - - - For positional arguments, terminate the option list with a - single marker after the last option, and - include the data at the right position. The - marker terminates option processing, and - the data will not be treated as an option even if it starts - with a dash. - -
- -
- Passing secrets to subprocesses - - The command line (the name of the program and its argument) of - a running process is traditionally available to all local - users. The called program can overwrite this information, but - only after it has run for a bit of time, during which the - information may have been read by other processes. However, - on Linux, the process environment is restricted to the user - who runs the process. Therefore, if you need a convenient way - to pass a password to a child process, use an environment - variable, and not a command line argument. (See .) - - - Portability notice - - On some UNIX-like systems (notably Solaris), environment - variables can be read by any system user, just like command - lines. - - - - If the environment-based approach cannot be used due to - portability concerns, the data can be passed on standard - input. Some programs (notably gpg) - use special file descriptors whose numbers are specified on - the command line. Temporary files are an option as well, but - they might give digital forensics access to sensitive data - (such as passphrases) because it is difficult to safely delete - them in all cases. - -
-
- -
- Handling child process termination - - When child processes terminate, the parent process is signalled. - A stub of the terminated processes (a - zombie, shown as - <defunct> by - ps) is kept around until the status - information is collected (reaped) by the - parent process. Over the years, several interfaces for this - have been invented: - - - - - The parent process calls wait, - waitpid, waitid, - wait3 or wait4, - without specifying a process ID. This will deliver any - matching process ID. This approach is typically used from - within event loops. - - - - - The parent process calls waitpid, - waitid, or wait4, - with a specific process ID. Only data for the specific - process ID is returned. This is typically used in code - which spawns a single subprocess in a synchronous manner. - - - - - The parent process installs a handler for the - SIGCHLD signal, using - sigaction, and specifies to the - SA_NOCLDWAIT flag. - This approach could be used by event loops as well. - - - - - None of these approaches can be used to wait for child process - terminated in a completely thread-safe manner. The parent - process might execute an event loop in another thread, which - could pick up the termination signal. This means that libraries - typically cannot make free use of child processes (for example, - to run problematic code with reduced privileges in a separate - address space). - - - At the moment, the parent process should explicitly wait for - termination of the child process using - waitpid or waitpid, - and hope that the status is not collected by an event loop - first. - -
- -
- <literal>SUID</literal>/<literal>SGID</literal> - processes - - - Programs can be marked in the file system to indicate to the - kernel that a trust transition should happen if the program is - run. The SUID file permission bit indicates - that an executable should run with the effective user ID equal - to the owner of the executable file. Similarly, with the - SGID bit, the effective group ID is set to - the group of the executable file. - - - Linux supports fscaps, which can grant - additional capabilities to a process in a finer-grained manner. - Additional mechanisms can be provided by loadable security - modules. - - - When such a trust transition has happened, the process runs in a - potentially hostile environment. Additional care is necessary - not to rely on any untrusted information. These concerns also - apply to libraries which can be linked into such processes. - - -
- Accessing environment variables - - The following steps are required so that a program does not - accidentally pick up untrusted data from environment - variables. - - - - Compile your C/C++ sources with -D_GNU_SOURCE. - The Autoconf macro AC_GNU_SOURCE ensures this. - - - Check for the presence of the secure_getenv - and __secure_getenv function. The Autoconf - directive AC_CHECK_FUNCS([__secure_getenv secure_getenv]) - performs these checks. - - - Arrange for a proper definition of the - secure_getenv function. See . - - - Use secure_getenv instead of - getenv to obtain the value of critical - environment variables. secure_getenv - will pretend the variable has not bee set if the process - environment is not trusted. - - - - Critical environment variables are debugging flags, - configuration file locations, plug-in and log file locations, - and anything else that might be used to bypass security - restrictions or cause a privileged process to behave in an - unexpected way. - - - Either the secure_getenv function or the - __secure_getenv is available from GNU libc. - - - Obtaining a definition for <function>secure_getenv</function> - - - -#ifndef HAVE_SECURE_GETENV -# ifdef HAVE__SECURE_GETENV -# define secure_getenv __secure_getenv -# else -# error neither secure_getenv nor __secure_getenv are available -# endif -#endif -]]> - - -
-
- -
- Daemons - - Background processes providing system services - (daemons) need to decouple themselves from - the controlling terminal and the parent process environment: - - - - Fork. - - - - In the child process, call setsid. The - parent process can simply exit (using - _exit, to avoid running clean-up - actions twice). - - - - - In the child process, fork again. Processing continues in - the child process. Again, the parent process should just - exit. - - - - - Replace the descriptors 0, 1, 2 with a descriptor for - /dev/null. Logging should be - redirected to syslog. - - - - - Older instructions for creating daemon processes recommended a - call to umask(0). This is risky because it - often leads to world-writable files and directories, resulting - in security vulnerabilities such as arbitrary process - termination by untrusted local users, or log file truncation. - If the umask needs setting, a restrictive - value such as 027 or 077 - is recommended. - - - Other aspects of the process environment may have to changed as - well (environment variables, signal handler disposition). - - - It is increasingly common that server processes do not run as - background processes, but as regular foreground process under a - supervising master process (such as - systemd). Server processes should - offer a command line option which disables forking and - replacement of the standard output and standard error streams. - Such an option is also useful for debugging. - -
- -
- Semantics of command line arguments - - - After process creation and option processing, it is up to the - child process to interpret the arguments. Arguments can be - file names, host names, or URLs, and many other things. URLs - can refer to the local network, some server on the Internet, - or to the local file system. Some applications even accept - arbitrary code in arguments (for example, - python with the - option). - - - Similar concerns apply to environment variables, the contents - of the current directory and its subdirectories. - - - - Consequently, careful analysis is required if it is safe to - pass untrusted data to another program. - -
- -
- <function>fork</function> as a primitive for parallelism - - A call to fork which is not immediately - followed by a call to execve (perhaps after - rearranging and closing file descriptors) is typically unsafe, - especially from a library which does not control the state of - the entire process. Such use of fork - should be replaced with proper child processes or threads. - -
- - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Serialization.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/Serialization.xml deleted file mode 100644 index 60427c5..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Serialization.xml +++ /dev/null @@ -1,397 +0,0 @@ - - - - Serialization and Deserialization - - Protocol decoders and file format parsers are often the - most-exposed part of an application because they are exposed with - little or no user interaction and before any authentication and - security checks are made. They are also difficult to write - robustly in languages which are not memory-safe. - - -
- Recommendations for manually written decoders - - For C and C++, the advice in applies. In - addition, avoid non-character pointers directly into input - buffers. Pointer misalignment causes crashes on some - architectures. - - - When reading variable-sized objects, do not allocate large - amounts of data solely based on the value of a size field. If - possible, grow the data structure as more data is read from the - source, and stop when no data is available. This helps to avoid - denial-of-service attacks where little amounts of input data - results in enormous memory allocations during decoding. - Alternatively, you can impose reasonable bounds on memory - allocations, but some protocols do not permit this. - -
- -
- Protocol design - - Binary formats with explicit length fields are more difficult to - parse robustly than those where the length of dynamically-sized - elements is derived from sentinel values. A protocol which does - not use length fields and can be written in printable ASCII - characters simplifies testing and debugging. However, binary - protocols with length fields may be more efficient to parse. - -
- -
- Library - support for deserialization - - For some languages, generic libraries are available which allow - to serialize and deserialize user-defined objects. The - deserialization part comes in one of two flavors, depending on - the library. The first kind uses type information in the data - stream to control which objects are instantiated. The second - kind uses type definitions supplied by the programmer. The - first one allows arbitrary object instantiation, the second one - generally does not. - - - The following serialization frameworks are in the first category, - are known to be unsafe, and must not be used for untrusted data: - - - - Python's pickle and cPickle - modules - - - Perl's Storable package - - - Java serialization (java.io.ObjectInputStream) - - - PHP serialization (unserialize) - - - Most implementations of YAML - - - - When using a type-directed deserialization format where the - types of the deserialized objects are specified by the - programmer, make sure that the objects which can be instantiated - cannot perform any destructive actions in their destructors, - even when the data members have been manipulated. - - - JSON decoders do not suffer from this problem. But you must not - use the eval function to parse JSON objects - in Javascript; even with the regular expression filter from RFC - 4627, there are still information leaks remaining. - -
- -
- XML serialization - - -
- External references - - XML documents can contain external references. They can occur - in various places. - - - - - In the DTD declaration in the header of an XML document: - - - -]]> - - - - - - In a namespace declaration: - - - -]]> - - - - - - In an entity defintion: - - - - -]]> - - - - - - In a notation: - - - -]]> - - - - - - Originally, these external references were intended as unique - identifiers, but by many XML implementations, they are used - for locating the data for the referenced element. This causes - unwanted network traffic, and may disclose file system - contents or otherwise unreachable network resources, so this - functionality should be disabled. - - - Depending on the XML library, external referenced might be - processed not just when parsing XML, but also when generating - it. - -
-
- Entity expansion - - When external DTD processing is disabled, an internal DTD - subset can still contain entity definitions. Entity - declarations can reference other entities. Some XML libraries - expand entities automatically, and this processing cannot be - switched off in some places (such as attribute values or - content models). Without limits on the entity nesting level, - this expansion results in data which can grow exponentially in - length with size of the input. (If there is a limit on the - nesting level, the growth is still polynomial, unless further - limits are imposed.) - - - Consequently, the processing internal DTD subsets should be - disabled if possible, and only trusted DTDs should be - processed. If a particular XML application does not permit - such restrictions, then application-specific limits are called - for. - -
- -
- XInclude processing - - XInclude processing can reference file and network resources - and include them into the document, much like external entity - references. When parsing untrusted XML documents, XInclude - processing should be truned off. - - - XInclude processing is also fairly complex and may pull in - support for the XPointer and XPath specifications, - considerably increasing the amount of code required for XML - processing. - -
- -
- Algorithmic complexity of XML validation - - DTD-based XML validation uses regular expressions for content - models. The XML specification requires that content models - are deterministic, which means that efficient validation is - possible. However, some implementations do not enforce - determinism, and require exponential (or just polynomial) - amount of space or time for validating some DTD/document - combinations. - - - XML schemas and RELAX NG (via the xsd: - prefix) directly support textual regular expressions which are - not required to be deterministic. - -
-
- Using Expat for XML parsing - - By default, Expat does not try to resolve external IDs, so no - steps are required to block them. However, internal entity - declarations are processed. Installing a callback which stops - parsing as soon as such entities are encountered disables - them, see . - Expat does not perform any validation, so there are no - problems related to that. - - - Disabling XML entity processing with Expat - - - - This handler must be installed when the - XML_Parser object is created (). - - - Creating an Expat XML parser - - - - It is also possible to reject internal DTD subsets altogeher, - using a suitable - XML_StartDoctypeDeclHandler handler - installed with XML_SetDoctypeDeclHandler. - -
- -
- Using OpenJDK for XML parsing and validation - - OpenJDK contains facilities for DOM-based, SAX-based, and - StAX-based document parsing. Documents can be validated - against DTDs or XML schemas. - - - The approach taken to deal with entity expansion differs from - the general recommendation in . - We enable the the feature flag - javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, - which enforces heuristic restrictions on the number of entity - expansions. Note that this flag alone does not prevent - resolution of external references (system IDs or public IDs), - so it is slightly misnamed. - - - In the following sections, we use helper classes to prevent - external ID resolution. - - - Helper class to prevent DTD external entity resolution in OpenJDK - - - - Helper class to prevent schema resolution in - OpenJDK - - - - - shows the imports used by the examples. - - - Java imports for OpenJDK XML parsing - - -
- DOM-based XML parsing and DTD validation in OpenJDK - - This approach produces a - org.w3c.dom.Document object from an input - stream. - use the data from the java.io.InputStream - instance in the inputStream variable. - - - DOM-based XML parsing in OpenJDK - - - - External entity references are prohibited using the - NoEntityResolver class in - . - Because external DTD references are prohibited, DTD validation - (if enabled) will only happen against the internal DTD subset - embedded in the XML document. - - - To validate the document against an external DTD, use a - javax.xml.transform.Transformer class to - add the DTD reference to the document, and an entity - resolver which whitelists this external reference. - -
- -
- XML Schema validation in OpenJDK - - - shows how to validate a document against an XML Schema, - using a SAX-based approach. The XML data is read from an - java.io.InputStream in the - inputStream variable. - - - SAX-based validation against an XML schema in - OpenJDK - - - - The NoResourceResolver class is defined - in . - - - If you need to validate a document against an XML schema, - use the code in - to create the document, but do not enable validation at this - point. Then use - - to perform the schema-based validation on the - org.w3c.dom.Document instance - document. - - - Validation of a DOM document against an XML schema in - OpenJDK - - -
-
-
- -
- Protocol Encoders - - For protocol encoders, you should write bytes to a buffer which - grows as needed, using an exponential sizing policy. Explicit - lengths can be patched in later, once they are known. - Allocating the required number of bytes upfront typically - requires separate code to compute the final size, which must be - kept in sync with the actual encoding step, or vulnerabilities - may result. In multi-threaded code, parts of the object being - deserialized might change, so that the computed size is out of - date. - - - You should avoid copying data directly from a received packet - during encoding, disregarding the format. Propagating malformed - data could enable attacks on other recipients of that data. - - - When using C or C++ and copying whole data structures directly - into the output, make sure that you do not leak information in - padding bytes between fields or at the end of the - struct. - -
- - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Temporary_Files.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/Temporary_Files.xml deleted file mode 100644 index d78bad7..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/Temporary_Files.xml +++ /dev/null @@ -1,257 +0,0 @@ - - - - Temporary files - - In this chapter, we describe how to create temporary files and - directories, how to remove them, and how to work with programs - which do not create files in ways that a safe with a shared - directory for temporary files. General file system manipulation - is treated in a separate chapter, . - - - Secure creation of temporary files has four different aspects. - - - - - The location of the directory for temporary files must be - obtained in a secure manner (that is, untrusted environment - variables must be ignored, see ). - - - - - A new file must be created. Reusing an existing file must be - avoided (the /tmp race - condition). This is tricky because traditionally, system-wide - temporary directories shared by all users are used. - - - - - The file must be created in a way that makes it impossible for - other users to open it. - - - - - The descriptor for the temporary file should not leak to - subprocesses. - - - - - All functions mentioned below will take care of these aspects. - - - Traditionally, temporary files are often used to reduce memory - usage of programs. More and more systems use RAM-based file - systems such as tmpfs for storing temporary - files, to increase performance and decrease wear on Flash storage. - As a result, spooling data to temporary files does not result in - any memory savings, and the related complexity can be avoided if - the data is kept in process memory. - - -
- Obtaining the location of temporary directory - - Some functions below need the location of a directory which - stores temporary files. For C/C++ programs, use the following - steps to obtain that directory: - - - - - Use secure_getenv to obtain the value - of the TMPDIR environment variable. If - it is set, convert the path to a fully-resolved absolute - path, using realpath(path, NULL). Check - if the new path refers to a directory and is writeable. In - this case, use it as the temporary directory. - - - - - Fall back to /tmp. - - - - - In Python, you can use the tempfile.tempdir - variable. - - - Java does not support SUID/SGID programs, so you can use the - java.lang.System.getenv(String) method to - obtain the value of the TMPDIR environment - variable, and follow the two steps described above. (Java's - default directory selection does not honor - TMPDIR.) - -
- -
- Named temporary files - - The mkostemp function creates a named - temporary file. You should specify the - O_CLOEXEC flag to avoid file descriptor leaks - to subprocesses. (Applications which do not use multiple threads - can also use mkstemp, but libraries should - use mkostemp.) For determining the - directory part of the file name pattern, see . - - - The file is not removed automatically. It is not safe to rename - or delete the file before processing, or transform the name in - any way (for example, by adding a file extension). If you need - multiple temporary files, call mkostemp - multiple times. Do not create additional file names derived - from the name provided by a previous - mkostemp call. However, it is safe to close - the descriptor returned by mkostemp and - reopen the file using the generated name. - - - The Python class tempfile.NamedTemporaryFile - provides similar functionality, except that the file is deleted - automatically by default. Note that you may have to use the - file attribute to obtain the actual file - object because some programming interfaces cannot deal with - file-like objects. The C function mkostemp - is also available as tempfile.mkstemp. - - - In Java, you can use the - java.io.File.createTempFile(String, String, - File) function, using the temporary file location - determined according to . - Do not use java.io.File.deleteOnExit() to - delete temporary files, and do not register a shutdown hook for - each temporary file you create. In both cases, the deletion - hint cannot be removed from the system if you delete the - temporary file prior to termination of the VM, causing a memory - leak. - -
- -
- Temporary files without names - - The tmpfile function creates a temporary - file and immediately deletes it, while keeping the file open. - As a result, the file lacks a name and its space is deallocated - as soon as the file descriptor is closed (including the implicit - close when the process terminates). This avoids cluttering the - temporary directory with orphaned files. - - - Alternatively, if the maximum size of the temporary file is - known beforehand, the fmemopen function can - be used to create a FILE * object which is - backed by memory. - - - In Python, unnamed temporary files are provided by the - tempfile.TemporaryFile class, and the - tempfile.SpooledTemporaryFile class provides - a way to avoid creation of small temporary files. - - - Java does not support unnamed temporary files. - -
- -
- Temporary directories - - The mkdtemp function can be used to create - a temporary directory. (For determining the directory part of - the file name pattern, see .) - The directory is not automatically removed. In Python, this - function is available as tempfile.mkdtemp. - In Java 7, temporary directories can be created using the - java.nio.file.Files.createTempDirectory(Path, String, - FileAttribute...) function. - - - When creating files in the temporary directory, use - automatically generated names, e.g., derived from a sequential - counter. Files with externally provided names could be picked - up in unexpected contexts, and crafted names could actually - point outside of the tempoary directory (due to - directory traversal). - - - Removing a directory tree in a completely safe manner is - complicated. Unless there are overriding performance concerns, - the rm program should be used, with - the and options. - -
- -
- Compensating for unsafe file creation - - There are two ways to make a function or program which excepts a - file name safe for use with temporary files. See - , - for details on subprocess creation. - - - - - Create a temporary directory and place the file there. If - possible, run the program in a subprocess which uses the - temporary directory as its current directory, with a - restricted environment. - Use generated names for all files in that temporary - directory. (See .) - - - - - Create the temporary file and pass the generated file name - to the function or program. This only works if the function - or program can cope with a zero-length existing file. It is - safe only under additional assumptions: - - - - - The function or program must not create additional files - whose name is derived from the specified file name or - are otherwise predictable. - - - - - The function or program must not delete the file before - processing it. - - - - - It must not access any existing files in the same - directory. - - - - - It is often difficult to check whether these additional - assumptions are matched, therefore this approach is not - recommended. - - - -
- diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/schemas.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/schemas.xml deleted file mode 100644 index 8e84245..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/schemas.xml +++ /dev/null @@ -1,4 +0,0 @@ - - - - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-Expat-Create.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-Expat-Create.xml deleted file mode 100644 index dd8724d..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-Expat-Create.xml +++ /dev/null @@ -1,17 +0,0 @@ - - - - -XML_Parser parser = XML_ParserCreate("UTF-8"); -if (parser == NULL) { - fprintf(stderr, "XML_ParserCreate failed\n"); - close(fd); - exit(1); -} -// EntityDeclHandler needs a reference to the parser to stop -// parsing. -XML_SetUserData(parser, parser); -// Disable entity processing, to inhibit entity expansion. -XML_SetEntityDeclHandler(parser, EntityDeclHandler); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-Expat-EntityDeclHandler.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-Expat-EntityDeclHandler.xml deleted file mode 100644 index 2a982f4..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-Expat-EntityDeclHandler.xml +++ /dev/null @@ -1,16 +0,0 @@ - - - - -// Stop the parser when an entity declaration is encountered. -static void -EntityDeclHandler(void *userData, - const XML_Char *entityName, int is_parameter_entity, - const XML_Char *value, int value_length, - const XML_Char *base, const XML_Char *systemId, - const XML_Char *publicId, const XML_Char *notationName) -{ - XML_StopParser((XML_Parser)userData, XML_FALSE); -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-Errors.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-Errors.xml deleted file mode 100644 index 928d79b..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-Errors.xml +++ /dev/null @@ -1,22 +0,0 @@ - - - - -class Errors implements ErrorHandler { - @Override - public void warning(SAXParseException exception) { - exception.printStackTrace(); - } - - @Override - public void fatalError(SAXParseException exception) { - exception.printStackTrace(); - } - - @Override - public void error(SAXParseException exception) { - exception.printStackTrace(); - } -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-Imports.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-Imports.xml deleted file mode 100644 index 61f0965..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-Imports.xml +++ /dev/null @@ -1,27 +0,0 @@ - - - - -import javax.xml.XMLConstants; -import javax.xml.parsers.DocumentBuilder; -import javax.xml.parsers.DocumentBuilderFactory; -import javax.xml.parsers.ParserConfigurationException; -import javax.xml.parsers.SAXParser; -import javax.xml.parsers.SAXParserFactory; -import javax.xml.transform.dom.DOMSource; -import javax.xml.transform.sax.SAXSource; -import javax.xml.validation.Schema; -import javax.xml.validation.SchemaFactory; -import javax.xml.validation.Validator; - -import org.w3c.dom.Document; -import org.w3c.dom.ls.LSInput; -import org.w3c.dom.ls.LSResourceResolver; -import org.xml.sax.EntityResolver; -import org.xml.sax.ErrorHandler; -import org.xml.sax.InputSource; -import org.xml.sax.SAXException; -import org.xml.sax.SAXParseException; -import org.xml.sax.XMLReader; - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-NoEntityResolver.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-NoEntityResolver.xml deleted file mode 100644 index e1d1049..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-NoEntityResolver.xml +++ /dev/null @@ -1,15 +0,0 @@ - - - - -class NoEntityResolver implements EntityResolver { - @Override - public InputSource resolveEntity(String publicId, String systemId) - throws SAXException, IOException { - // Throwing an exception stops validation. - throw new IOException(String.format( - "attempt to resolve \"%s\" \"%s\"", publicId, systemId)); - } -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-NoResourceResolver.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-NoResourceResolver.xml deleted file mode 100644 index 6eae01a..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK-NoResourceResolver.xml +++ /dev/null @@ -1,17 +0,0 @@ - - - - -class NoResourceResolver implements LSResourceResolver { - @Override - public LSInput resolveResource(String type, String namespaceURI, - String publicId, String systemId, String baseURI) { - // Throwing an exception stops validation. - throw new RuntimeException(String.format( - "resolution attempt: type=%s namespace=%s " + - "publicId=%s systemId=%s baseURI=%s", - type, namespaceURI, publicId, systemId, baseURI)); - } -} - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-DOM.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-DOM.xml deleted file mode 100644 index f04a2af..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-DOM.xml +++ /dev/null @@ -1,19 +0,0 @@ - - - - -DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); -// Impose restrictions on the complexity of the DTD. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// Turn on validation. -// This step can be omitted if validation is not desired. -factory.setValidating(true); - -// Parse the document. -DocumentBuilder builder = factory.newDocumentBuilder(); -builder.setEntityResolver(new NoEntityResolver()); -builder.setErrorHandler(new Errors()); -Document document = builder.parse(inputStream); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_DOM.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_DOM.xml deleted file mode 100644 index b4ecf6c..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_DOM.xml +++ /dev/null @@ -1,23 +0,0 @@ - - - - -SchemaFactory factory = SchemaFactory.newInstance( - XMLConstants.W3C_XML_SCHEMA_NS_URI); - -// This enables restrictions on schema complexity. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// The following line prevents resource resolution -// by the schema itself. -factory.setResourceResolver(new NoResourceResolver()); - -Schema schema = factory.newSchema(schemaFile); - -Validator validator = schema.newValidator(); - -// This prevents external resource resolution. -validator.setResourceResolver(new NoResourceResolver()); -validator.validate(new DOMSource(document)); - diff --git a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_SAX.xml b/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_SAX.xml deleted file mode 100644 index 2f6c6c9..0000000 --- a/defensive-coding/tmp/en-US/xml_tmp/Tasks/snippets/Serialization-XML-OpenJDK_Parse-XMLSchema_SAX.xml +++ /dev/null @@ -1,26 +0,0 @@ - - - - -SchemaFactory factory = SchemaFactory.newInstance( - XMLConstants.W3C_XML_SCHEMA_NS_URI); - -// This enables restrictions on the schema and document -// complexity. -factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); - -// This prevents resource resolution by the schema itself. -// If the schema is trusted and references additional files, -// this line must be omitted, otherwise loading these files -// will fail. -factory.setResourceResolver(new NoResourceResolver()); - -Schema schema = factory.newSchema(schemaFile); -Validator validator = schema.newValidator(); - -// This prevents external resource resolution. -validator.setResourceResolver(new NoResourceResolver()); - -validator.validate(new SAXSource(new InputSource(inputStream))); -