English subtitles

← 07-25 Security

Get Embed Code
3 Languages

Showing Revision 1 created 06/29/2012 by Amara Bot.

  1. Let's take a break and talk a bit about computer security--
  2. a topic we really haven't touched on much in this unit so far.
  3. Security can sometimes be defined as computing in the presence of an adversary--
  4. someone else using a computer or a network or resources
  5. who means you hard or hopes to exploit or take advantage of resources
  6. resources that you've put out there.
  7. It just so happens--you'll be surprised to discover I am breaking this news--
  8. that the internet is not secure.
  9. Malicious agents or adversaries can write malicious webpages or JavaScript fragments.
  10. The simplest way to do this would be to write a JavaScript fragment that loops forever--
  11. some sort of version of Fibonacci that has no stopping condition
  12. that just keeps going and going and going.
  13. Then as soon as you've directed your browser to that page, it would stall,
  14. and you'd be denied some server. You wouldn't be able to use your computer.
  15. In practice, browsers often put some sort of timeout on script execution.
  16. I'll run your script for 3 or 4 seconds, and after that if it hasn't finished, I'd better stop.
  17. that's one of the reasons why optimization is so important, but it also has this security angle.
  18. If we make any mistakes when we're designing our web browser,
  19. then outside agents might break in to our computers and gain access
  20. to sensitive documents--our tax returns, our personal email, or whatnot.
  21. We want to make sure that that doesn't happen.
  22. Let's listen to someone who knows quite a bit more about security than I do
  23. talk about how this plays out in the real world with web browsers.
  24. The web can be a great place but it can also be a dangerous place.
  25. Nothing stops users from posting malicious code or websites
  26. or writing scripts that will trying to take advantage of your computer or your browser.
  27. There might be security holes or exploits, they're sometimes called, that allow this.
  28. I was wondering if you might talk a bit about security at the language or implementation level
  29. from the perspective of Mozilla.
  30. Absolutely. Security is a prevalent concern at Mozilla.
  31. When I was growing up, the idea of getting a piece of software was that you actually
  32. drove to a store and you looked at a shelf and you pulled a box off the shelf
  33. and you paid somebody and you took it home and that piece of software was sold to you
  34. by a company that you trusted, by a third party that you trusted,
  35. so you had some sense of this piece of software that I'm about to put on my computer
  36. is something that I can believe is going to do something on behalf,
  37. not something against me.
  38. The web doesn't work like that way at all.
  39. The way web applications work is you can go to any website anywhere in the world,
  40. and somebody you've never met and never seen and that nobody can vouch for you
  41. is going to run some of their code that they wrote on your computer.
  42. So that changes the game.
  43. That means that in order to build a serious platform where programs can do important things
  44. on your behalf, we need to make sure that they can't also do important things against you.
  45. The more people put valuable parts of their lives onto the web like their bank account,
  46. for example, the more we have important assets to defend.
  47. One of the concepts people talk about a lot in security is the notion of the trust computing base.
  48. When you download some code from some third party that you don't know,
  49. if we're being kind of maximally pessimistic we say, well, I don't trust this code completely.
  50. I'd like it to do something for me but I don't know for sure that it's not malicious.
  51. However, that code is running inside of a web browser like Firefox,
  52. and I do trust the code that was written by Mozilla. I do trust Firefox.
  53. In order to be able to say as much as we can about the security of a system,
  54. we'd like for the parts of the system that we need to trust the most
  55. to be as small as possible, so we talk about shrinking the trusted computing base,
  56. as being a goal of having the smallest possible amount of software where if it goes wrong
  57. disaster can ensue--like somebody can steal or credit card information or your bank account.
  58. All modern web browsers are implemented in C++.
  59. Now, C++ is a very powerful language. There are a lot of things that you can do with it.
  60. But it's also not a particularly safe language.
  61. It's a language where if you make one wrong move, if you make one little programming mistake,
  62. you can actually leave parts of your system open to malicious programs.
  63. For example, if you write a program in C++ and you have an array of data
  64. and you forget to make sure that the program doesn't go beyond the end of that array,
  65. in most programming languages you'll get a runtime error that says,
  66. "Oops. You tried to access beyond the end of the array."
  67. C++ doesn't give you that protection.
  68. What C++ does is it just keeps reading what ever happens to be in memory
  69. at the end of that array.
  70. Well, whatever happens to be in memory could actually be some part of the browser
  71. that has internal information like a password.
  72. It could also be some other program running on the system,
  73. and there are a lot of people out there who work on finding ways to exploit
  74. these kinds of bugs to use them to take control of your computer or to get access to your private data.
  75. The project of building a web browser that people can trust
  76. and building a web browser that operates on user's behalf
  77. is also one of building software that they can trust.
  78. In order to build software that they can trust,
  79. it needs to be built on top of programming technologies
  80. that we know we can work with effectively to build software that's not unsafe.
  81. We've been discussing malicious code like JavaScript written by evildoers
  82. that we would run in our interpreter. Running evil code seems really bad.
  83. Can't I just look at the source code and tell if it's bad before I run it
  84. and then not run the bad code? Why doesn't Mozilla do something like that.
  85. Unfortunately, it turns out that there's a lot of good theoretical computer science
  86. that shows us that that is a provably impossible problem.
  87. I don't know if you've discussed the halting program. >>We may have.
  88. It turns out that if I were able to prove that any particular piece of code was not malicious
  89. I would also be able to solve the halting problem,
  90. and we already know that that's an unsolvable problem in computer science.
  91. Looking at this maybe from a more positive side,
  92. that means that I'll always have a job.
  93. The law of compiler writer employability. >>Exactly.