Minor fixes.

Author: wangjohn

6.857/ps2.aux

@@ -17,4 +17,4 @@
 \newlabel{tocindent1}{17.77782pt}
 \newlabel{tocindent2}{29.38873pt}
 \newlabel{tocindent3}{0pt}
-\@writefile{toc}{\contentsline {subsection}{\tocsubsection {}{}{Phising}}{3}}
+\@writefile{toc}{\contentsline {subsection}{\tocsubsection {}{}{Phishing}}{3}}

6.857/ps2.log

@@ -1,4 +1,4 @@
-This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2012.9.12)  11 MAR 2013 18:54
+This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2012.9.12)  11 MAR 2013 21:23
 entering extended mode
  %&-line parsing enabled.
 **ps2.tex
@@ -579,28 +579,24 @@ Overfull \vbox (4.78334pt too high) has occurred while \output is active []
 Overfull \vbox (4.78334pt too high) has occurred while \output is active []
 
 
-[3] (./ps2.aux)
-
-LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.
-
- ) 
+[3] (./ps2.aux) ) 
 Here is how much of TeX's memory you used:
  12912 strings out of 495061
  252938 string characters out of 1182621
- 332014 words of memory out of 3000000
+ 332021 words of memory out of 3000000
  15682 multiletter control sequences out of 15000+50000
  9048 words of font info for 36 fonts, out of 3000000 for 9000
  189 hyphenation exceptions out of 8191
- 56i,6n,56p,1641b,203s stack positions out of 5000i,500n,10000p,200000b,50000s
-</usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmbx10.pfb></usr/sha
-re/texmf-texlive/fonts/type1/public/amsfonts/cm/cmcsc10.pfb></usr/share/texmf-t
-exlive/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/texmf-texlive/font
-s/type1/public/amsfonts/cm/cmmi7.pfb></usr/share/texmf-texlive/fonts/type1/publ
-ic/amsfonts/cm/cmr10.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/
-cm/cmr7.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmr8.pfb><
-/usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.pfb></usr/share/
-texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy7.pfb>
-Output written on ps2.pdf (3 pages, 125253 bytes).
+ 56i,6n,56p,1640b,203s stack positions out of 5000i,500n,10000p,200000b,50000s
+</usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmbx1
+0.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmcsc10.pfb></us
+r/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmmi10.pfb></usr/share/tex
+mf-texlive/fonts/type1/public/amsfonts/cm/cmmi7.pfb></usr/share/texmf-texlive/f
+onts/type1/public/amsfonts/cm/cmr10.pfb></usr/share/texmf-texlive/fonts/type1/p
+ublic/amsfonts/cm/cmr7.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfont
+s/cm/cmr8.pfb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy10.p
+fb></usr/share/texmf-texlive/fonts/type1/public/amsfonts/cm/cmsy7.pfb>
+Output written on ps2.pdf (3 pages, 125251 bytes).
 PDF statistics:
  51 PDF objects out of 1000 (max. 8388607)
  0 named destinations out of 1000 (max. 500000)

6.857/ps2.pdf

@@ -83,7 +83,7 @@ \subsection*{Problem 2.2.b}
      \end{enumerate}
 
  \subsection*{Problem 2.3.b}
-    Introducing a random canary variable after the return address should not prevent our approach from working.  By introducing a random canary value, the code will check whether or not this value has been overwritten at runtime.  Our approach only smashes the expectedhash value.  We do not try and overwrite the return adress or any other variables besides one local variable; therefore, this value should not be changed.
+    Introducing a random canary variable after the return address should not prevent our approach from working.  By introducing a random canary value, the code will check whether or not this value has been overwritten at runtime.  Our approach only smashes the expectedhash value.  We do not try and overwrite the return address or any other variables besides one local variable; therefore, this value should not be changed.
 
 \section*{Problem 2.4}
 
@@ -95,8 +95,8 @@ \subsection*{Pass-The-Hash-Toolkit Attack}
 
 To prevent this type of attack, one could make sure to encrypt all hashes as soon as they are created. This will prevent an attacker from being able to listen in on a communication line and obtain a hashed password, which would force the hacker to use brute force attempts to obtain the password. Second, one could make it harder to access the LsaLogonSessionArray except for the intended program. This could be done by randomly choosing a memory location to store the array and only allowing the intended program to store the reference to the array (making sure the reference location is also randomly chosen in memory).
 
-\subsection*{Phising}
+\subsection*{Phishing}
 
-One major attack that deserves attention is phishing. In these attacks, APT1 attackers send out emails that appear to be from company officials or customers that contain malicious attachments. These are effective because they attackers research who is most likely to send an email, and name the attachments so that they look genuine. There are several steps we can take to address this issue. As a cheap and immediate measure, we should make all employees aware of the issue by having managers inform them at their next meeting. However, more rigorous solutions involve securing our mail system. Because the danger is in the attachments and not the email, we could make it company policy (enforced by the mail client) to not send attachments at all, but share files through a central ftp server. In this case, we might prevent some of the phishing, but as we'd still need to open attachments from clients and send attachments to remote workers, an informed attacker could circumvent this policy. In addition, this may stifle collaboration between teams. I think the proper solution is to have cryptographically sign our emails. While employees can still send and receive emails from any source, they should disregard and report any email that appears to be from within the company but isn't properly signed. To deal with the emails that aren't from within the company, we'll need to license virus scanning software, which should be cheap with respect to the damage of an attack. In all cases, employees should be prevented from downloading executable attachments, as executables are never distributed through email.
+One major attack that deserves attention is phishing. In these attacks, APT1 attackers send out emails that appear to be from company officials or customers that contain malicious attachments. These are effective because they attackers research the most likely people to send out emails and label the attachments with genuine names. There are several steps we can take to address this issue. As a cheap and immediate measure, we should make all employees aware of the issue by having managers inform them at their next meeting. However, more rigorous solutions involve securing our mail system. Because the danger is in the attachments and not the email, we could make it company policy (enforced by the mail client) to not send attachments at all, but share files through a central ftp server. In this case, we might prevent some of the phishing, but as we'd still need to open attachments from clients and send attachments to remote workers, an informed attacker could circumvent this policy. In addition, this may stifle collaboration between teams. I think the proper solution is to have cryptographically sign our emails. While employees can still send and receive emails from any source, they should disregard and report any email that appears to be from within the company but isn't properly signed. To deal with the emails that aren't from within the company, we'll need to license virus scanning software, which should be cheap with respect to the damage of an attack. In all cases, employees should be prevented from downloading executable attachments, as executables are never distributed through email.
 
 \end{document}