CYBER -ITL- A501(c)3 Corporation
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Title of Series | ||
Number of Parts | 93 | |
Author | ||
License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
Identifiers | 10.5446/36270 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
00:00
SoftwareCyberneticsCyberneticsStudent's t-testInformationstheorieDemosceneDisk read-and-write headLevel (video gaming)
00:54
Pairwise comparisonInformation securityProduct (business)Public key certificateInformation securitySource codeResultantMaxima and minimaSoftware bugWeb browserData structurePerformance appraisalRight angleMultiplication signProcess (computing)Procedural programmingSoftwareComputer animation
03:03
Information securityCuboidGraphical user interfaceCartesian coordinate systemPatch (Unix)NumberPoint (geometry)Figurate numberSlide ruleWindowComputer architectureSoftware developerOffice suiteWeb browserSoftwareProduct (business)View (database)outputMobile appLevel (video gaming)ConsistencyConfidence intervalDifferent (Kate Ryan album)FinitismusGreatest elementMultiplication signBinary codeOperating systemDecision theoryCompilation albumProcess (computing)Set (mathematics)Computing platformQuicksortPairwise comparison1 (number)Dynamical systemOpen setHecke operatorAttribute grammarMoment (mathematics)BitNegative numberRun-time systemData analysisSoftware bugExploit (computer security)Functional (mathematics)Library (computing)Fluid staticsElectronic program guideBinary fileComplex (psychology)Continuum hypothesisRun time (program lifecycle phase)Fuzzy logicPeer-to-peerMetric systemMathematical analysisSurfaceMereologyPlotterTheory of relativityLine (geometry)TriangleInformation securityMeasurementVideo gameFood energyCycle (graph theory)Client (computing)
11:04
Mathematical analysisProduct (business)Binary codeCodeFunctional (mathematics)Integrated development environmentInformation securityLinker (computing)1 (number)Revision controlRandomizationComplex (psychology)Operator (mathematics)WhiteboardData storage deviceMetric systemComputer programMeasurementPrinciple of maximum entropyFront and back endsSoftwareFocus (optics)Category of beingHeuristicOpen sourcePhysical systemAreaRight angleQuicksortCartesian coordinate systemSemiconductor memoryStack (abstract data type)Computer-assisted translationSign (mathematics)Component-based software engineeringBootingAddress spaceBranch (computer science)Control flowPredictabilityCompilation albumFlagCompilerAttribute grammarMereologySoftware developerFirmwareType theory10 (number)Absolute valueSpherical capDirected graphINTEGRALPointer (computer programming)RootContinuum hypothesisLevel (video gaming)Motion captureSystem callBitDynamical systemSlide rule
15:35
Mathematical analysisFluid staticsFreezingAreaDrill commandsoutputSingle-precision floating-point formatPhysical systemSchmelze <Betrieb>CASE <Informatik>Core dumpBand matrixScaling (geometry)ResultantElectronic mailing listDistribution (mathematics)Hash functionWebsiteTable (information)Crash (computing)Denial-of-service attack1 (number)Right angleAsymmetryType theoryGoogolAlgorithmDynamical systemLinear regressionComputational complexity theorySoftwareEndliche ModelltheorieMathematicsQuicksortCategory of beingFunctional (mathematics)Power (physics)Statistical hypothesis testingBayesian networkCodeLevel (video gaming)FacebookMereologyFuzzy logicInheritance (object-oriented programming)Bus (computing)Vulnerability (computing)Integrated development environmentSoftware bugINTEGRALDifferent (Kate Ryan album)Mathematical analysisCausalityTerm (mathematics)Exploit (computer security)Goodness of fit
20:21
Mathematical analysisSet (mathematics)Graphical user interfaceFunction (mathematics)Library (computing)CodeConsistencyBitComputer fileCartesian coordinate systemAverageTotal S.A.MeasurementComputer programFunctional (mathematics)Traffic reportingGraphical user interfaceGroup actionNumberMaxima and minimaGoogle ChromePower (physics)Latent heatAttribute grammarWeb pageLine (geometry)SubsetSoftwareFlagView (database)InformationstheorieLevel (video gaming)Multiplication signTable (information)Category of beingSoftware bugComputer animation
22:55
View (database)Focus (optics)Web browserGraphical user interfaceView (database)Software developerTouchscreenCartesian coordinate systemMemory managementCASE <Informatik>Stack (abstract data type)Computer fileWeb browserWhiteboardPoint (geometry)Drop (liquid)ConsistencyOpen source
25:02
View (database)Focus (optics)Functional (mathematics)NumberOpen sourceBinary codeComputer fileBitRange (statistics)View (database)Hacker (term)Cartesian coordinate systemHeuristicMultiplication signCodeSource codeIntegrated development environmentGraph (mathematics)Dot productScaling (geometry)MereologySoftware developerDifferent (Kate Ryan album)CompilerPhysical system
28:22
Focus (optics)View (database)Function (mathematics)Multiplication signFunctional (mathematics)1 (number)Revision controlPointer (computer programming)Data storage devicePrinciple of maximum entropy
28:59
View (database)Focus (optics)CodeEntire functionMetric systemBinary codeCapability Maturity ModelComputer fileLevel (video gaming)Mechanism designFunctional (mathematics)Binary fileHypothesisVulnerability (computing)Figurate numberIntegrated development environmentScaling (geometry)Different (Kate Ryan album)Operating systemGoogol
30:40
Information securityDefault (computer science)32-bitGraphical user interfaceChainIntegrated development environmentSelf-organizationData storage deviceMultiplication signSoftware developerBuildingCartesian coordinate systemAreaRight angleBitComputer scienceBinary codeMemory managementFlagGoodness of fitPhysical systemProcess (computing)Computer programWindowFunctional (mathematics)Googol1 (number)Computer fileQuicksortComputer configurationGame controllerCodeMobile appElectronic mailing listCompilerWordFocus (optics)Operating systemBlind spot (vehicle)Different (Kate Ryan album)FrequencyData miningDistribution (mathematics)Revision controlSoftware
34:36
Mathematical analysisTraffic reportingOpen sourceHistogramFunctional (mathematics)Endliche ModelltheorieWindowLevel (video gaming)QuicksortMobile appSet (mathematics)Right angle
35:18
Open sourceOpen sourceFunction (mathematics)Source codeMathematical analysisBinary codeSelf-organizationSoftware developer
36:00
Wireless Markup LanguageOpen sourceAreaExploit (computer security)Address spaceBinary codeSoftware development kitRevision controlInformationSheaf (mathematics)Electronic mailing listWebsiteCompilerSoftwarePointer (computer programming)Shared memoryWeb pageRandomizationPlastikkarteNumberDefault (computer science)Integrated development environmentSymbol tableStapeldateiCartesian coordinate systemException handlingCyberneticsStack (abstract data type)Set (mathematics)Type theoryWindowRight angleHecke operatorEntropie <Informationstheorie>Hand fan1 (number)CompilerSource codeCompilation albumKernel (computing)Physical systemFunctional (mathematics)Dynamical systemView (database)Moving averageData structurePlotterOpen setLibrary (computing)BacktrackingMathematicsCausalityResultantMotion captureFlag
39:52
Context awarenessMetropolitan area networkMeta elementData modelFluid staticsAerodynamicsMeasurementMobile WebResultantMeasurementInformation privacyInformation technology consultingMathematical analysisQuicksortSubsetWebsiteConfiguration spacePatch (Unix)Fluid staticsCodeData analysisOrder (biology)Product (business)Sign (mathematics)DivisorOnline helpDecision theoryFood energyGame theoryBinary codeSelf-organizationBusiness modelSource codeVulnerability (computing)TheorySocial classDynamical systemSoftwareTraffic reportingData structureProcess (computing)TwitterLine (geometry)Right angleAxiom of choiceInternet der DingeBlind spot (vehicle)Information securityCheat <Computerspiel>Message passing1 (number)
44:09
CAN busScaling (geometry)Data analysisCore dumpHand fanSlide ruleResultantArithmetic meanARPANETTraffic reportingMultiplication signInformationstheorieMathematical modelTouch typingForcing (mathematics)
Transcript: English(auto-generated)
00:00
waiting with us uh I'm Mudge uh this is Sarah and we're going to give you a little uh uh information about the cyber independent testing lab uh you may have been reading about it kind of pull back uh the curtains and um so that's the introduction I'm gonna let Sarah start this off it kind of as a heads up uh we go a lot from like a 30,000 foot all
00:21
the way down into the weeds and then back up so um it's gonna be a little bumpy ride but hopefully it's enjoyable. We know different people are interested in different technical levels so we wanted to make sure we hit something for everyone uh but anyways uh this is just uh preliminary data peak behind the scenes so um if you visit our website it's mostly just
00:44
coming soon right now but uh this is what we're but uh uh this is uh what we're up to uh just a quick peak. Okay so first off uh what problem are we trying to address? It's the fact that uh we've been trying to get people to care about security for years but then whenever
01:05
somebody says okay I give I get that it's important what should I do? We don't have very much concrete data to give them. They don't have anything to act on. There's no consumer reports that uh for software security that tells them what's the safest browser and if
01:21
I put it out to the floor what's the safest browser we'd get a lot of very strong opinions but a lot of those opinions would be based on what feels true rather than actual data and that's the problem that nobody actually really has data. Um so uh what are the things
01:43
people are trying to do right now and why don't they work? First off there's certifications and evaluations which are frequently focused on processes and procedures and don't actually look at code or at the final product so they can't really speak to security. Um there's industry and marketing labels but these are frequently vague or
02:04
misleading um and they're they're not you can't compare between them. If two people have the same sticker on their product you don't know which of them did it better or which one did just the bare minimum and then stopped so it's not useful to a consumer. Um
02:20
source code review definitely has its place but it's not there to serve the consumer. It's the either an internal thing by the vendor or the vendor's paying somebody to do this on their product and they're the consumer doesn't see the results of this or whether the bugs that were found in review actually got fixed um and so it's just uh the
02:43
incentive structure there isn't right for consumer advocacy. And finally legislation is frequently well meaning but a lot of the time ends up trying to fix a problem by making it illegal to look at it and that's a terrible way to fix anything. So is this mic on? Can
03:06
folks hear me in the back? Great. Thank you. So I wanted to dive pretty quickly into some of the data um and just so you keep it in your mind we're measuring how difficult it is for an adversary how much work you can impose on an adversary to newly exploit a
03:21
piece of software. The more work you can impose on your opponent and you know without any work on your own you know the better off you are. So to date we've looked at about a hundred thousand binary applications um with about a hundred plus features uh static features we've got a whole bunch of dynamic ones we'll go into uh some difference there uh and uh measure you know as bug hunters and attackers and
03:44
exploiters which I've been doing that for twenty almost thirty years now um I'm old uh you know what did we see? So when you get such a large amount of data and applications and binaries and libraries to look at in an operating system you can build up these continuums so here's the first continuum. This is Linux Ubuntu and this is the
04:06
first uh ten thousand some odd binaries and the way you read this is the easier to exploit is further to the left going down to negative numbers here and you know we normalized up at a hundred percent on the far right and then the number of binaries
04:21
which are executables and libraries are you know uh bucketed into the columns of uh five point bins and with this you can kind of so the let me back up the installation is this is all the base software that comes with it plus most of the co- most common third party applications installed and because of this you can kind of pull in any of
04:41
the data sheets from the really detailed data uh extract uh the the the relevant metrics and kind of plot them so if we throw the first couple on here uh we're gonna do it on a relative hardening line underneath that's mapped to the top part and we'll take two common browsers Chrome and Firefox and Chrome you know did a little bit better it's a little
05:01
bit more difficult to exploit if you look at the underground market the cost of a zero day on Chrome bears that out it's uh slightly more expensive than a cost of a zero day for Firefox uh and then the yellow triangles up on top you know show where that is next slide we see a little further down um because we're we're approaching the only fifth percentile mark uh you start to see some of the office suites the client side
05:23
applications um for crowds like this this isn't that much of a surprise because we know that the people writing those you know it's it's they don't view themselves as the most common attack surface but it's also why client side attacks and attachments that get opened up by these are you know the easiest path to compromise and exploit um and next slide this
05:47
is OSX so we've done this on Linux OSX and Windows and we'll have some of the RTOS's and the other architectures coming online and instead of just the first ten thousand this is the thirty eight thousand so this is all of OSX uh El Captain uh and about twenty thousand
06:05
third party applications that we went out and measured uh and then plotted on here so let's see what this looks like now that we've kind of seen Linux we have a much wider spread for Chrome on the far right uh pretty decent almost approaching the ninety fifth percentile Safari and then Firefox is way down here and this was surprising to us uh it
06:25
was also surprising to the Firefox development team and they've now confirmed this as well um so that's nice and I'm going to get into what makes up these numbers to show you the depth of the data that we're extracting out of the binaries to give you some
06:41
confidence uh in how this is working and how it would be useful to you so let's look at some other applications out of these thirty some odd thousand well here are the different office suites that are available in OSX you've got Microsoft Office coming in again pretty close to the bottom fifth percentile uh OpenOffice and you know Mac uh Apple's
07:02
Office again all on one particular platform I should point out with this sort of view from the data it is important to only do comparisons within the same platform so it's not fair to say oh how did Firefox on Apple do compared to Explorer on Windows because they have different attributes and different traits I mean and the compilation settings are
07:22
different but we'll go into that and more so let's pull out a few more examples because it's nice to have something on the far right and the far left and why not let it be the very software that installs the security patches for your product anyway um yeah that's a little disappointing to see the Microsoft Office updater being a negative 7.5 uh I was
07:42
talking to a team uh that I believe might be involved with uh some of the zero days going around that are popping a lot of the OSX boxes on El Captain and I said uh you know any any clues as to you know how you're going in and they said oh you'll figure it out and I went back to them I said all the boxes that you're going in on have uh
08:01
Microsoft Office installed don't they and they're like well maybe um and this is a real quick way of looking at not only as a defender being able to choose and say hey if all things are even and I can kind of choose which office suite because it doesn't matter to me I'm going to choose the one that imposes more work to my opponent and that's kind of the goal. The flip side on the offensive side as the adversary is I want to choose the lowest
08:24
hanging targets because I've got finite amount of resource and time as well so why am I going to go after OSX's software updater if I see Microsoft's updater listening on the network and taking input? Okay this is the base just the base no other apps we haven't finished this one yet of Windows 10 and I wanted to pull this out because this is
08:44
really impressive because this is a level of consistency that we didn't see in the base of um Linux uh when we were looking at the base uh before we added in all the other ones we did not see this in OSX and the development life cycle and the compilation process that
09:00
Microsoft has imposed this is way different than what it looked like on Windows XP um because you can see they're very consistent with what they put in there are a few on the bottom that's because there's this one set of applications that I did install it's the big data analytics package it was installed on all three it was the bottom in all three and we're going to point out the lessons learned on that one in a moment as well. Rest
09:23
assured as we put in more third party applications and as we start to flesh out more of the binary and more of the dynamic feature sets this is going to start becoming a bit more uh dispersed but right now this was this is kudos Microsoft knows what the heck they're doing on Windows um the previous slide we might question if they know what
09:41
they're doing as well on OSX. Into the micro bunch. Alright so the we've shown you some numbers but you probably want to know what kind of data we're looking at to produce those numbers uh and we're there's a lot of other industries that have trained consumers in how to make complex technical decisions so in figuring out how to help consumers make
10:03
security software decisions we're drawing from those. So first off we've got our static analysis features things where we're measuring aspects of the application without running it and this is like the nutritional facts for the software which functions were used and what are the complexity values etc um and then uh the runtime testing the uh
10:28
dynamic stuff where we're fuzzing and you know crash testing is like crash testing cars you know so the monroney sticker that you see in any new car that you're buying uh you know tells you how it did in crash testing and what's its uh EPA expected miles per
10:44
gallon things like that. And then um the safety continuum where you see where that software falls compared to its peers or to the rest of that software environment uh that's like energy guide where you find out you know how much does this fridge to run cost to run monthly versus another one or what have you. In the uh static part
11:13
which is a large amount of what went into creating those scores on the back end on the continuums that you saw um and is really gonna be the focus of most of this talk here
11:23
although we will talk about what we're doing on the dynamic aspect um includes essentially the hundred plus featured uh extractions in the following three categories. Measurements of complexity uh turn out to be very very important not only because um you know the more complex something is the more difficult it is for the
11:42
developers or the creators to have gotten it right and then for other people to ensure its correctness in operation and function and intent um but because it works across the board. I mean we can do things like just the code size as a simple metric example up through measures of branch prediction complexity through uh stack adjusts in rack and stack
12:02
those up through more complex uh things such as cyclomatic complexity for functions and this works across any sort of operating system in fact it works on any binaries all the way down to extracting them off of firmware from televisions or cars and this is a nice way of comparing you know how complex you know product A is versus how complex products B product B is. The other areas are a bit more specific to the types of
12:25
operating systems and development environments themselves. So application armory is a catch all that we say for all of the features that can be imposed and buttressed into and uh reinforced in the binary from the compilation stage so if you sla- do slash GS in
12:42
Microsoft it will try to go in and do stack uh protection by putting stack guards in uh if you do dash D fortify source on OSX or Linux uh it'll go in and look at 72 common risky functions and see if it can't do heuristics to replace them with a safer version um and you know the more recent uh modern advances have control flow integrity, code pointer
13:04
integrity to prevent ROP etcetera, return on your programming. Then there's the linker so this is you know where address based layout randomization comes in uh is important and of course there's lots of measurements not just is it turned on or not but you know is it high entropy uh how ubiquitous is it across all of the components etcetera etcetera and
13:23
then the loader which is you know what's ultimately run at the very end right when the application is put in and is being told how to mark memory as executable or not. These are all very important safety features in fact some of these are mu- are akin to automobiles with like the seat belts, the airbags, the anti lock brakes. If I'm buying a piece
13:42
of software or using a piece of software that doesn't have address based layout randomization fortified source and stack guards I'm buying a car that doesn't have you know seat belts and airbags and ABS and I need to know that because they've been around for decades and they definitively and demonstrably and quantifiably have made applications more difficult to exploit. In fact uh um some of the capture the flag uh
14:05
people when they want to make an easier challenge binary they just go get an older compiler that doesn't have those attributes and they build it cause it's much easier to exploit. And then the final part is developer hygiene so here's about five hundred uh common function calls across POSIX and ANSI that historically have been the root
14:24
urbane of memory correct uh corruption uh code and data uh uh confusion etcetera. And we break those out into the following buckets. There's ICK functions there's only a few of these if you remember the poison sticker underneath uh your your kitchen sink for the
14:41
detergents and stuff you know that's ICK. If you see an ICK function like get S in commercial code run screaming those people should not be doing commercial code. And then there's the classic bad functions which are difficult to use correctly the unbounded stir copies some of the mem copies etcetera um risky ones which you know the bounded
15:00
versions and more recently we have some good functions that are hard to use incorrectly like the stir lcat stir l copies uh done very nicely. The problem is the only people who know about those good functions are folks who cared about security in the first place and we don't teach those in school or anything else. When you see those in the code in the binary um that's a really good sign. But it's not as good of a
15:22
sign when you don't see a consistent use of them and you see the risky and the bad ones next to it. So anyway these are all the sorts of things that we're pulling out of all of those you know tens hundreds of thousands of binaries from the static component. When we next slide please. Right before I go into the dynamic dynamic one uh which I'll just talk briefly about we're gonna do a bunch of deep dives just showing you deep
15:44
dives looking at one or two of those static sort of features and then kinda pop the stack back up cause it gets way too much in the weeds otherwise. Dynamic fuzzing cause it's really nice to say like well this looks like it's a super soft target um but it's even better to say we know we can get a crash with a sig bus or illegal uh instruction or you
16:03
know whatever sig seg v. Right now we're using AFL. AFL is fantastic. It gives us good enough coverage um and we use it for three specific results. One of them is the exploitability because our environment we really care about exploitability cause you
16:22
know we're bug hunters we like to write exploit code but that's not always the most important thing for different consumers which is why we call out the level of disruptability as well. Think about a big business. Think about one that's doing offshore oil drilling. Um they care much more about the disruptability than the exploitability and if you ask them they'll say if our system crashes the drill bit stops.
16:46
The molten core solidifies and that offshore oil rig goes offline for more than twelve months as we have to build a new one push it out there. I don't care I don't want the system to be compromised and exploited but if it is I'd rather they're on IRC or doing it as a wares distribution site and they didn't crash the system. You go talk to a
17:08
company that doesn't crash rather than be exploited in a way that we can't trust the integrity of the underlying data and we're propagating bad information and before too long we can't unroll and and and uh re uh reclaim the books. And then the final one
17:21
which is a new one and I'm calling this out here because this is about two three four hopefully longer off but it's coming and this is algorithmic complexity and this matters to any large distributed companies like your LinkedIn's, your Facebook's, your Google's uh because they're pretty impervious to distributed denial of service because
17:41
they've got more bandwidth than you know well they are the world's bandwidth uh for all intents and purposes and they're just distributed and decentralized but when you can find a small amount of input that causes the worst case in a particular types of algorithms so a linked list devolves or a hash table devolves to a linked list you can
18:02
start taking these guys out and they can't defend against it. The traditional DDoS defenses de aggregate, decentralize, increase bandwidth don't work and so based upon how we modify AFL we can get all three of these but fuzzing's expensive. Fuzzing's expensive so we'd like to do as little of it as we need to um and so what but on the other
18:26
hand math is cheap uh so what we're doing is fuzzing a statistically significant portion of the software and then using Bayesian math and linear regression so that we can model how the rest of the software would do uh because we don't care about finding a
18:45
specific exploit we want to know what categories of function of uh vulnerabilities are present and what sorts of problems do we expect to see and for that we can model that based off of the static features um the uh uh like somebody who's actually looking for an
19:01
exploit still has to do all that heavy lifting but for our risk assessments we don't need that so uh some software will have a little A in the corner saying actual we really fuzz this and then some things will have a little E saying it's estimated um and uh that's the um that's the icing on the cake the part that would make this scale really
19:21
well for you know. And mathematically we can show you to what level we're able to accurately predict this you know 99.99 whatever we have and this isn't too unusual you're actually used to this in a different area explain you know the cars. Right so uh like for the EPA miles per gallon they don't run every single car until it's on fumes they do it for enough so that they can understand and model how the rest of
19:44
the cars will do you know assuming no one's trying to trick them with uh. Yeah Volkswagen figured out a way around that right. And so we would continue to do spot checking and if we find an anomaly that goes back into our model but it should work really nicely long term for us and uh even out one of the uh traditional asymmetries of
20:04
defender and attacker because this is something that works really well for defense not so well for offense. Yeah one of the things I learned when I was uh uh deputy director of ATEP out in Google and got to see how Google did things is um don't underestimate the power of Bayesian analysis and linear regression testing. So go ahead. Okay so we're going
20:24
to uh I'm just gonna set this up for Sarah uh I mentioned we want to take you on a deep dive on just uh some small subsets to show you uh kind of the power of what you can do when you start to really tease out information on specific attributes from the binary extraction uh and uh then we'll pop back up to a higher level view of the world again.
20:45
Okay so um this is one of our automatically generated reports for Google Chrome on OSX and uh I got to spend lots of quality time with I can never remember whether people prefer LaTeX or you know I read it more than I say. So um the first page is always first a table
21:06
that gives the rubric for how scores were achieved because as we tweak things we want to be able to look at old reports and remember how we got those numbers and then uh after that we get a summary of any anomalies for the file so did it have any weird flags that
21:21
you don't normally see or strange initial permissions or what have you? Uh how did it do for function consistency which uh we'll talk about in a little bit and then uh the file code and data size for the main application, average library, total libraries and then all of that together. Um because you know the I mean Google Chrome the main
21:45
application is just 601 bytes of code it's a stub all the action is happening in the libraries and when you look at the libraries it links to directly and then the libraries they link to and so on down the rabbit hole eventually Chrome is using 176 libraries so we
22:03
put out that number and then the average and minimum library scores that occurred too. And then the next page is the the main report obviously there's more than one page of this if there's 176 libraries so this is just the first page but uh um the first line will be the main application and then all of the libraries listed after that and uh for e then
22:26
the columns are whether it's 32 or 64 bit what score did it get and then two categories of features that we're highlighting here are application armoring and function uh hygiene. Um and so the application armoring are the you know safety features that make software
22:45
better and then the uh function hygiene is a measure of how well do the programmers know what they're doing. Go ahead. Okay so that's more detailed view this is a very core screen view comparing three browsers on OSX and uh what we have here is that we're just
23:05
looking at four application armoring features ASLR, non executable heap, stack guards and fortified source and uh if all the files for your browser had ASLR enabled that would be 25 points uh if you had all if all files had all four features you'd get a hundred points
23:26
which no one did. Um but Google Chrome comes out ahead because they had pretty consistent application of ASLR and non executable heap. Uh Safari did not quite so well they had all four of those things present in some cases but just not consistently and then
23:45
Firefox was missing ASLR entirely which was a shock to us and then if you looked at the uh Bugzilla comments it was a shock to the development team. So it was quite interesting because Kim Zetter did a very nice article uh on us in um I can't remember the name of the uh the journal uh and some folks on Firefox dev team popped up and
24:06
said well that doesn't make sense we've had ASLR since 2000 mumble mumble and it was enjoyable in a kind of you know awkward way to watch some of the other developers point out all the situations where they intentionally disabled it and guess kind of what we might have
24:21
measured and somebody said well wait a second they've got Safari and that doesn't live on other things this must be OSX we have ASLR and OSX don't we? And then somebody goes and looks and goes no uh not at all and they dig it out and it's like sure enough for backwards compatibility you know for uh from 10.6 OSX you know they had to drop it out. Now the good news is in September they're going to rectify that they won't be able to fix I
24:45
don't I don't it doesn't look like they're going to try and fix the non executable heap the way Chrome Google Chrome did which is a bummer um so but the good news is a fix is coming based upon this data uh we'll see how well it goes across the board the bad news is until then I don't know what the recommendation is maybe use Chrome. So that
25:03
was a view of uh just a few of the application armoring uh call outs so let's dive down into just one specific one uh since the data on the back end that we're using for all this is actually pretty rich and this is the Fortify source and I gave you a little for those who aren't familiar with this there are 72 functions I think it's 72 presently um that the
25:24
compiler uh has replacement safer versions for and if you say Fortify source on Linux or OSX it'll go through and see if you have any of the functions in your code there do a bunch of heuristics on each one to see if it can guess what you had really intended and then replace that risky function with one that's more strongly bounded so it'll kind of like do
25:44
some extra safety for you and put that into the resulting binary so we looked at um the Linux applications and across so uh across all of those there were about 2 million opportunities for a risky function to be uh enforced or improved with Fortify source and the
26:01
way you read this graph is that each one of these dots is a file and on along the x axis is what percentage of the opportunities of those risky functions it found it was able to replace in the file and on the y axis is the number of those risky functions per file so the far left you know a little bit off uh is there's a file with over 10,000 risky
26:23
functions that was only able to replace about 7% of those uh for those who are Linux hackers uh system d a kind of extremely important uh uh binary uh for Linux was off the scale how many? 43,000 opportunities mostly p reads and it was able to successfully
26:44
reinforce those less than 7 tenths of 1% of the time and the interesting part here is that the developer is trying to do the right thing I mean the right thing would not to be used those risky functions in the first place but sometimes you're kind of you're kind of opposed and have to so they told it Fortify source but then they don't know the
27:01
efficacy or the coverage that it got and the consumer needs to know that as well because the fact that two people have anti-lock breaks is a lot different than the fact that one of them will stop within 300 yards and one of them will stop within 10 yards and depending on your environment you need to be able to know each so this gave us a nice view of source code fortification across Linux how does it look across OSX?
27:21
First a couple other things for this chart the uh a third of the files end up being in the 95 to 100% range and then the rest were really evenly distributed from 0 to 95% and the interesting thing to note is that some of these very well fortified close to 100% files are up at like 25,000 functions so it it's not that they've only had 5 functions
27:44
and that's why it got 100% okay now moving on. But it also means that two thirds of the time it's not able to protect you uh when it's putting on there so this is OSX and you can see it's weighted a little bit towards the other side in fact there weren't any functions uh any binaries that had a significant number of functions that were
28:03
uh completely fortified the 95 to 100% one uh the largest one had like 121 uh functions that that were replaced uh and this led us to believe that source code fortification is lagging behind in OSX as to what it is on Linux so we dove into the data and decided to slice and dice this one more way and look at it per function so remember
28:25
there are 72 functions and the way you read this chart is the far left one says there were about 37 functions out of those 72 that were never 0 to 5% of the time were they ever able to be fortified and replaced far right you see that there were 15 functions that
28:41
almost all the time uh were able to be replaced successfully with the safer versions the far right makes up essentially your stir copies your unbounded ones there that it says I know what you're trying to do the far left all of your pointer arithmetic on mem copies largely but there were 28 functions out of there that never got touched they're essentially academic. So with our hypothesis that it's a little more mature on Linux
29:09
than it is on OSX what did OSX look like? That's not that good. So there were you know 50 plus uh out of the 72 that are you know only ever occasionally and then a whole slew
29:22
of them well 52 or 0% out of the 72 so this is a way of using the data rather than looking at a per binary of looking at an entire environment and figuring out its maturity level as a consumer as to the different safety mechanisms that are in place. And here where there were 15 functions that were 95 to 100% fortified in Linux here there's
29:40
only one in the 90 to 95 bin and then nothing was 100% fortified. So you can see that it's a much less mature feature on OSX. Okay um and uh a lot of the things we're looking at are not new things to be looking for they're things that attackers always look
30:01
at when they're trying to find a weak target and figure out how to target their efforts. But usually they look until they find something that looks juicy and then they start working on that. Uh it's as far as we know nobody's ever applied these metrics across the entire ecosystem to see on a broad scale what it all looks like. So and I
30:22
wanted to add we've shown you at the beginning an example of looking at individual files the last couple showed you looking at an entire operating system and kind of the maturity level and now what Sarah's gonna walk you through is if you step back and look at the institutions that made the code and what you can infer about them that maybe they don't even know about themselves. So what we're gonna look at is Google
30:43
Chrome and Microsoft Excel on OSX and what you can learn about the OSX development uh for those two organizations. And what you can see uh as I'm gonna explain is that each organization has something they do very well and each organization has a blind spot. So first off uh the application armoring features what they really tell us about is the
31:05
development and build environments for the the software developers. Um and that's an area where Google Chrome does very well. They actually had the only 64 bit files on OSX that had the non executable heap flag enabled uh out of the almost 40,000 binaries that we
31:30
have. They did a great job there uh and- They figured out how to manually go in and hack the binaries because they knew the operating system and the ABI would allow you to explicitly call that out even though the comp- you know the compiler chains don't give you the
31:41
option to do that. And they said hey OSX tries to make the heap non executable by default but it's a system wide control and we can explicitly say no it should never be executable for our app please. And a lot of you might be surprised that for at least a period of time it was executable on all of your distributions. Some of them it might still be. So uh they went above and beyond to make sure that they had the best de-
32:05
development and build environment. On the other hand Microsoft Excel was still a 32 bit binary and they didn't have some of the application armoring features that are default for 32 bit binaries on OSX uh if you're doing a modern build chain. And so what we can
32:21
infer from this is that either they were using a really old build system for OSX because it's not their wheelhouse. Their main focus is of course Windows development. Or that they were using a modern build environment and specifically disabled it. So we're giving them the benefit of the doubt and assuming that it's just a really old
32:41
compiler. Um but then uh on the other hand uh let's look at function hygiene. So Google Chrome has more use of good functions than Excel does. But all of those binaries that had good functions also had the risky and bad versions of the same functions. Which sort of defeats the purpose. Uh you know the if you're gonna use the
33:04
stir L copy always use stir L copy don't also have stir copies right next to it. Um on the other hand Microsoft Excel when they use the good function they just use the good function. They uh they don't have the stir copies in there anymore because they got beat up for them too many times and they don't let their developers use them
33:22
now. Um and uh so this is an area where Microsoft has learned the hard lessons and is really doing the right thing. But uh at Google it's a little bit of the wild west. It's some developers know about the good functions and so they'll catch it and code review or use the right function from the beginning. But other ones don't and so it's
33:42
sort of luck of the draw. Yeah and they have I mean they have really good programmers at Google. This isn't a knock on them but you know not all of them are security uh as their main focus. Uh and it's a little bit of luck of the draw to who you get as the reviewer as well. But Microsoft in their pre-compiler has a dirty words list
34:00
essentially and you've seen this on their deprecated you know uh these functions are too risky for security we will not let you ship you know if you're using that out of Microsoft. So it flags them refuses to go to a gold build and they have to go back and actually replace it. So it's an institutionally enforced area. Which is impressive. And uh this is also just to plug a different pet peeve of
34:21
the uh variants and what you see from security knowledge of developers is also just the fault of computer science curriculum. That it's not something that's included for general computer science. Uh but anyways moving on back on talk back on topic. Okay. Uh this is the the sort of curated report that we're doing automatically off of the
34:44
data sets. And it's only highlighting those sub functions out of app armoring and uh and the function hygiene. But what we're doing is as the non-profit we're opening up and licensing the data sources so other folks can cut it and slice it and dice it any way they want for their own analysis. But we're modeling it off of consumer reports to figure out
35:02
something that's in the middle that will give consumers the ability to kind of look at a high level of what's going on. Go ahead. And if we pop back to the big picture and you think back to the histograms of Linux OSX and the and the the the early one on Windows. There was something because we always we always want to know um you know with the
35:23
attacker hat on what's in the far left what's making up all that low hanging fruit. Next. And we had installed the same package on all 3 of them and there was a package that had about 600 binaries. Uh if you are any startup in Silicon Valley working with big data you probably rely heavily on this uh as do a lot of larger organizations. And it
35:44
really surprised us because um this would not have been picked up with source code analysis which is also another reason other than we won't don't want to be under NDA's because we want to be able to give you the output why we don't look at source. Because source is the developers intent but the binaries is the actual ground truth. So what
36:00
is that? And that's the story of something called Anaconda. Go ahead. We were looking at address space layout randomization uh and measuring the efficacy uh in some of the Linux areas and this is a view of the number of dynamically of dynamic of dynamic symbols that are fixed on the X axis and the number of function pointers that are fixed
36:20
on the Y axis. You want everything to be 0 0. That means you've got all the ASLR that the kernel can do as much as it can to try and protect you against particular types of attacks. Anything moving up to the top right is getting worse and worse and worse and worse. So we were like what the heck are all of these? And we looked at it and we saw that ooh a bunch of them are all from the same package what's going on?
36:42
And that's where we decided to look into this particular package. Go ahead. Um it's a DARPA funded package um which is a little embarrassing I mean I had a lot of fun at DARPA and I'm a huge fan I'm a booster you saw cyber grand challenge that was that that was history actually uh that's going on and um you know they'll be the first ones to say look
37:04
this is sometimes it's about rapid prototyping but as a consumer I need to know where I'm accepting more risk than I ever expected. It's a roll up it's a whole bunch of open source software for R and Python with all of your numpy and pandas and your cyplot and then it's got you know open SSL libraries and XML and libcurl all precompiled and packaged
37:23
together. It is super convenient I mean it's like back tracker Kali for Linux cause it's a royal pain in the butt to try and put that stuff together and get it working on your own somebody else does it. Yay! And I roll it out the problem is on all of our systems I mean and I'm not the only one that's rolled it out here's the customer list from their um from their website uh it's major fortune 10 companies you know everything from
37:45
Bank of America Siemens every to DOD and what have you um so how large is the footprint when you install it and why is it the bottom score on all of these operating systems for 600 plus binaries because we had these binaries from other kits other things
38:02
used open SSL and had the binaries there and they weren't scoring as low so what was up with that and as we looked across them um they had the old version of the uh segment and section layout for Linux which you know implied that was weird cause you can overwrite in strange ways they were missing things like basic stack guards uh even on OSX
38:21
almost everybody that's been default for the comp for the compiler settings for eons and on Windows uh no high entropy uh um address based layout randomization no safe structured exception handlers yeah no it refixed it again Microsoft thinks it's G rather than SEH or for that's fine so we finally were able to get the ground truth as to why this
38:43
was happening because on Linux um they put in the uh the dot info section it spits in the compiler version in the build environment and their most recent uh batch of binaries is being recompiled from all the source code on uh what 2008 GCC running on a 2005 installation of Linux those were different defaults back then and it missed all of those
39:04
safety features all of those anti-lock breaks airbags seatbelts side you know side impact etcetera so I hadn't realized that they had essentially done the same trick unintentionally that the capture the flag folks do to make very easy targets for exploitation uh they missed almost a decade worth of improvements and you saw how well
39:23
that worked for Google on the compiler tool change by staying up to date on the latest and greatest um so that's a kind of interesting little side story we figured we'd share about why binary looking at binaries rather than source actually sometimes isn't the uh deficiency that many people think it is. Uh just to wrap things up there's been various
39:46
misconceptions about what we're doing or not so this is me making sure that we've uh got everyone on the same page as us. So these are preliminary results the uh detailed data releases are planned for end of this year early next year uh the goal of this was just to
40:02
familiarize everyone with what we're doing um and as we've stated we do binary only analysis partially because we don't want to be beholden to vendors or have to have NDA signed or anything like that but also because in a lot of ways source code is the theory whereas binaries are the ground truth and we want to see what the consumer gets. Um
40:22
this is not a pass fail you get a gold star sort of thing it's meant to be quantified and comparable between different products and uh we look at overall classes of vulnerabilities and trends rather than specific instances so we're not going to be like you know giving you oh there's an exploit on this line of whatever you know um
40:44
but we will tell you that this will be exploitable at a 99.9% uh percentage and that the adversary still has to do all the heavy work in order to do it so finally an asymmetric win for the consumer and the defender. This talk focused just on the static analysis because we had to pick a silo to focus on but uh we the dynamic analysis
41:03
results are planned to be released next year um and we are also going to be looking at uh internet of things devices again next year. Um we're a 501C3 which means we're a nonprofit charitable organization uh the with non-exclusive rights to use the IP we are going to be
41:25
offering uh the ability to license our data or to uh um uh you know other partnerships with corporations just not with the corporations that make the software. This was actually a really important uh choice that we made because we needed the incentive
41:40
structures to be aligned that would enable us nay force us to be able to give out the data uh to everybody and there are a couple of other efforts here I know folks are familiar with the more traditional underwriters laboratory you might not be aware and I hope that they do well I'm not sure I'm I'm I'm a booster of their approach they're now a for profit organization and it's a for profit organization based on public
42:02
safety and to me those are fundamentally misaligned incentive structures uh and then of course what they're doing is a bit more of the did you do all of the 40 EAL common criteria which we've already demonstrated really are just measurements of your processes and not what the safety is in the end product. We're partnering with uh consumer reports for
42:21
some things right now. Yeah consumer reports is involved with us. But consumer reports is sort of business model is what we're think of that for what we're going to be doing. Yeah if you're wondering how are they going to make money or how are they going to do anything else look at consumer reports and we're trying to do it the exact same way that they do we won't accept things from vendors we will go out and buy the software and analyze it ourselves or get it the same way you do off of the download
42:42
sites. The legitimate ones. And finally one thing a lot of people ask us about is we're not looking at software configuration, vendor history, how quickly they put out patches, interpreted code, corporate policies, privacy any of those things it's not that we think they're unimportant it's just that that data is already out there other people
43:00
are looking at it and we're trying to focus on the blind spot the thing that no one has data on yet. And uh you know we've uh compared the what we're doing to nutritional facts so you know having the nutritional facts on the thing is great but you still sometimes need a doctor or a dietitian so the security specialists the you know
43:21
consultants they can tell you what diet you should be on for software and they can also bring in all these other factors and you know help uh put it into a whole picture for you. Yeah we aren't telling you what to buy or what not to buy we don't want to do that we want to tell you what's inside of it so that you can make your own informed decision the same way that I enjoy my candy bar I want to eat my candy bar um but
43:43
I do want to know you know what it's made of and I actually enjoy it more when I know how many calories of sugar and I'm cheating. And since we've just got one minute left. Yeah so I'm flying through this this is what we're gonna see at the end of the year some of those curated data releases coming online we're gonna release in detail on the site our static measurement methodology so other folks can
44:01
recreate and do it we are not releasing the actual source code because that's uh a gaming issue um but we're releasing enough data so that you can recreate it on your own. 2017 the large scale data analytics dumps and everything else uh in and of things and then the large scale fuzzing results and the mathematic models are going to be released more publicly and described publicly in 2017. Two slides I gotta get to the these are our
44:22
thanks DARPAFL AFL community uh capstone uh Ford Foundation is funding us through consumer reports we've got some money from DARPA I'm huge fans they took the risk on us and this is the mandatory slide at the end uh because we have DOD funding inside of it but it's basic research meaning that we can publish without having to go ask permission um because this information just needs to be out there is that this does not necessarily
44:44
represent their opinions or anything else from the air force. DARPA said me too make sure me too and then the white house says why do you keep name dropping us all the time would you please knock it off um but so be it. Thank you very much. Finally if you want to get in touch with us.