Security.page

TODO Nemesis: Preventing Authentication & Access Control Vulnerabilities in Web Applications -zeldovich

resources

- magic string from skipfish: `-->">'>'"<sfi000142v524891>`
- <http://www.cs.berkeley.edu/~daw/teaching/cs261-f08/>

everything you need to know about cryptography in 1 hour (talk by collin
percival)

- hashing
  - ideal hash function: collision-resistant & one-way; nothing else
    - collision-resistant: hard to find 2 inputs w same hash
    - one-way: hard to find input given hash
    - nothing else: in particular, knowing $H(x)$ may let attacker compute
      $H(y)$ for some $y$, so simple hashing in itself is unsuitable for
      authentication/signing
    - don't use for symmetric signing
    - use SHA-256 (SHA-2); consider SHA-3; avoid MD2, MD4, MD5, SHA-1, RIPEMD
  - symmetric authentication aka symmetric signing: uses MACs
    - ideal MAC $f_k(x)$ uses key $k$ to map any-len input to $n$-bit output
      such that even if you know a $(x, f_k(x))$ pair, it's hard to generate
      another $(y, f_k(y))$, unlike in hashing
    - avoid having 2 msgs result in same data being input to MAC; ie take care
      w delimiters, don't simply concatenate things
    - use HMAC-SHA256; avoid CBC-MAC, Poly1305
    - don't leak timing side channels when verifying signatures (no early
      returns)
  - side channels: timing, EM emissions (TEMPEST), power consumption, microarch
    features (caches, HyperThreading)
  - block ciphers: TODO
  - TODO finish
- <http://www.bsdcan.org/2010/schedule/attachments/135_crypto1hr.pdf>
- <http://blip.tv/file/3627639>

people

- michal zalewski: google security person, wrote browsersec book among tons of
  other literature/tools
- jeremiah grossman: prominent web security blogger; leader of whitehat
  security, purveyor of web application firewalls
- theo de raadt: openssl, openbsd
- mark dowd: amazing; ibm x-force team; taossa book; nacl exploits; flash null
  ptr exploit
- mark miller: exploits, reveng, rootkits; joined windows 8/2008
- james whittaker: testing; joined windows 5/2006; joined google 6/2009
- crispin cowan: stackguard, immunix, subdomain, apparmor; joined windows from
  novell 1/2008
- michael howard: windows security team lead
- niels provos: principal engr at google; libevent, libio, openssh privsep;
  malware work

industry

- infrastructure (network/host) vs (web) application security
  - infrastructure: $9.1B to secure $98.5B assets (9.23%)
  - application: $750M to secure $64.4B assets (1.2%)
  - <http://jeremiahgrossman.blogspot.com/2010/02/infrastructure-vs-application-security.html>

vulnerability databases

- MITRE Common Vulnerabilities and Exposures (CVE)

misc terms

- _side-channel attack_: exploits physical implementation (vs. brute force or theoretical weakness); in crypto
- _covert channel_: channel that draws BW from another channel; in info theory
  - eg timing attacks: latency tells you whether logged in, whether query
    succeeds/fails (document contains term), how much of password you match
    (page-aligning password), etc
- _drive-by download_: browser (or extension) exploit triggered on simply
  displaying a page
- security assurance techniques: pentesting, code review, platform defenses,
  training, architectural/design analysis
- advanced persistent threat (APT): eg chinese gov attacking google

security models

- clark-wilson integrity model: semi-formal model
  - 2 categories of data, known-good (trusted) and unknown (untrusted)
  - mandatory checks to filter data before moving it from unknown to known-good
  - mandatory checks that data must be in the known-good state before it can
    participate in sensitive ops
  - eg: virus scanner than forces checking of all files as they're opened
- bell-lapuda (BPL) privacy model: formal model and policy
  - "data diode": info only flows in not out; useful for eg CIA
  - label-based access control; formal models of security allow for proofs
  - hugely influential in academic security research
- biba integrity model: dual of BPL model, for integrity instead

high level exploit classification

- confused deputy: fool a privileged process to do things for you
- arbitrary code execution: take over and do things yourself

access control

- _discretionary access control (DAC)_: subjects can xfer perms to others;
  decentralized
  - commonly in practice: objs have owners who controls perms
  - capability systems: subjects can xfer perms to others
- _mandatory access control (MAC)_: policy controlled by admin only; centralized
- _role-based (RBAC)_: restrict system access to authorized users
  - newer alt to MAC/DAC; can sim MAC/DAC
  - users are assigned particular roles; roles are assigned permissions
  - basically, roles are a level of indirection
  - qualitatively/typically, more fine-grained than ACLs, enumerating specific
    high-level operations

integrity control TODO

security

- confidentiality: aka privacy, secrecy
- integrity: eg phishing, MITM, hijacking, forgery
- availability: eg DOS

incorrect/missing MIME type exploits

- from <http://code.google.com/p/skipfish/wiki/KnownIssues>

  > Missing or mismatched MIME types on any files with user-controlled contents
  > may easily lead to cross-site scripting flaws. This is because of browser
  > content sniffing logic, a problem is particularly pronounced in Microsoft
  > Internet Explorer - where even something as subtle as returning image/jpeg
  > on a GIF file may cause HTML detection to be attempted, possibly
  > interpreting any HTML stuffed in the EXIF fields of an otherwise valid
  > image.

- example from <http://osvdb.org/show/osvdb/54773>

  > Simple Machines Forum contains a flaw that allows a remote cross site
  > scripting attack. This flaw exists because the application uses the
  > incorrect MIME type 'image/bmp'. The unknown header triggers MIME sniffing
  > in Internet Explorer, allowing an image to be falsely identified as
  > text/html. This could allow a user to create a specially crafted image
  > that would execute arbitrary code in a user's browser within the trust
  > relationship between the browser and the server, leading to a loss of
  > integrity.

S/MIME: TODO

- http://en.wikipedia.org/wiki/S/MIME
- http://weblog.infoworld.com/udell/2004/03/23.html

C++

- new/delete[]: if eg you have an array created with new[] and then
  accidentally delete[] a pointer not pointing to the head, then you can
  overwrite in the previous element the mem that delete[] treats as the length
  field
  - gcc: delete[] consults vtable of each object indepdently
  - msvc: delete[] consults vtable of first object only
  - harder on msvc, but can still do interesting things if eg dtor itself does
    anything interesting with the object data, eg free a pointer or set a value
- new[]/delete: you can cause coalescing by setting the `prev` bit in the
  malloc header, among other things

high-level code injection, encoding/parsing vulns

- unescaped input
- unicode: bad multibyte chars can bypass poor standard-library
  escapers/filters and validators/scanners unscathed
  - dynamic langs like sql and html/js
  - specific case of parser errors
  - eg: UTF-7
    - can encode ascii, eg `+ADw-` for `<`
    - IE interprets html/javascript using UTF-7 by default, and others use
      UTF-7 if a UTF-7 encoding appears anywhere early on (hence, `title`,
      `meta`, etc are targets)
    - need to check that all places handling this interpret it/escape it
      correctly, eg need to specify UTF-7 to php escaper `htmlentities()`
    - <http://shiflett.org/blog/2005/dec/google-xss-example>
  - eg: multi-byte encoding
    - eg, adding slashes (php `addslashes()`) is insufficient
    - `addslashes("\xbf27")` is '\xbf5c27', and '\xbf5c' is a valid char in
      GBK, swallowing the slash/letting the quote work
    - <http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string>
- parser errors: unhandled cases leading to unesacped input

sandboxing pitfalls

- ptrace: race conditions
  - ptrace behavior: suspends thread; mon reads args (regs, mem) separately
    - monitor can rewrite syscalls
  - multi-threaded arg race (TOCTTOU)
    - A syscalls; monitor checks; B changes args
    - works only on args that are not in regs, eg ptrs to other mem (file paths)
    - heavy-handed soln: prohibit multithreading
    - soln: suspend all threads
      - only for syscalls that use such ptrs ("volatile" syscalls)
      - if block all syscalls, then deadlock
        - devs use syscalls for sync (eg read and write)
        - authors don't know of any such pair of syscalls where one is volatile
  - another process could modify args via shared mem
    - heavy-handed soln: prohibit forking, shared mem
    - soln: or suspend all processes
  - fork-attach race
    - sandbox doesn't immediately attach to a forked child (!)
    - forked child can secretly fork another child monitor won't know about
    - soln: change call from fork to clone; has option to start in ptraced mode
  - FS race: trickiest; use symlinks to break security
    - prisoner does syscall involving path
    - monitor looks up path, following symlinks, to verify
    - another process/thread replaces a component in path with symlink to
      secure region in FS (eg user's $HOME)
    - soln: suspend threads
  - signals TODO
    - avoid by denying signals
  - alts to syscalls
    - lcall7 and lcall27 call gates; removed from most modern linuxes
  - MITRE CVE has over 40 ptrace-related items
  - refs
    - <http://iacoma.cs.uiuc.edu/~greskamp/pdfs/598cz.pdf>
    - NaCl
- chroot
  - TODO
  - (obv) can still make arbitrary syscalls; FS is only one part of sandboxing

web

- flash: `<embed...allowScriptAccess="always">` instead of `"sameDomain"`
- _HTTP parameter pollution (HPP)_ variants: multi-value, OOO value, malformed
  value, malformed request methods
- clickjacking: tricking the user into clicking something on a target site
  - eg by loading target in transparent iframe overlaid atop an enticing
    button, with a form submission button positioned exactly at the right place
  - mitigations: framekiller or framebuster: check `top==self`

low-level exploits

- buffer overflow
  - defenses
    - stack canaries: choose random int at process start and insert before
      return addr
      - random xor canaries: xor with the return addr to make sure it's not
        tampered with
      - propolice: gcc's impl; enhanced version of stackguard (never officially
        impl'd in gcc)
      - visual studio: /gs
    - nonexecutable stack: in windows, called Data Execution Prevention
      - NX bit: in page table entries; XD bit in intel, enhanced virus
        protection in amd
      - segments can be readable/writeable/executable, but modern OS's use flat
        memory model (pages instead of segments)
    - address space layout randomization (ASLR): randomize codes, heap, stacks
      - against return-to-libc (arbitrary code can still detect things)
- null pointer exploits: TODO
- heap overflow: overwrite eg a struct's function pointer or malloc block
  header
- heap spray: give you a place to place executable code, eg if stack is NX or
  your overriding return addr is constrained somehow
  - spray it everywhere to increase chances of landing in it
  - common in web browser js engines
  - nozzle: msr project that uses sled detection then reduces false positive
    rate with "global heap health metric"
- parser errors: unhandled cases
- format string attacks: eg printf(untrusted_input())
  - eg use %s and %x to print data from stack or other memory locations
  - defenses: statically check format strings
- integer overflow: unexpected number, either negative or large
  - eg size header in messages
  - controls things like strncpy/memcpy for overwrites
  - controls allocations (malloc) for large, unrealizeable mallocs that return
    null
  - also, arithm overflow
- null pointers
  - as write vector: use bad alloc to get ptr = null, where app later does
    *(ptr + offset) = value (where offset and value are user-controlled) to
    write a function ptr (flash exploit)
  - if the ptr is dereferenced and fields are accessed, first prep by writing
    to those fields
- return-to-libc: execute existing code via return ptr, circumventing NX
  - eg `system("bash")`
  - ASLR defends against this
  - techniques to make multiple function calls:
    - `%esp` lifting: for `-fomit-frame-pointer`
      - functions end in `addl $LOCAL_VARS_SIZE, %esp; ret`
      - after args to function, pad enough so that next function ptr is where
        %esp would point and thus the system would return to
    - frame faking: for programs w frame pointer
      - functions end in `leave; ret`
      - put in fake `ebp`s (frame ptrs) that point to function, followed by a
        ptr to a `leave;ret`
      - the very first return should point to a `leave;ret`
return oriented programming

- _continuation of execution_: resume app normally after exploit payload

same-origin policy (SOP)

- policies
  - for DOM access: scripts can access another page's functions/data iff from
    same site (in another frame/window)
    - scripts run in context of includer, not source; can't xhr or DOM-manip
      google
  - for XHR: only time when SOP restrict doc retrieval; html elements can
    source any domain
  - for cookies
  - for flash
    - `crossdomain.xml`: primarily protects access to the host containing the
      `crossdomain.xml`, specified with `allow-access-from`
      - careless wildcard usage opens up holes; eg flickr's api (since isolated
        to a separate domain)
    - can make same-origin HTTP reqs
    - can make same-host TCP conns on any high port
  - for java: applets can only see site it's downloaded from
    - can interact with the embedding page via JSObject API iff `mayscript` set
      in `applet` tag
    - DOMService API allows cross-site embedding pages to be accessed freely!
      with no `mayscript` opt-in, directly contradicting JSObject API
    - ability to send same-origin HTTP reqs using browser stack via
      URLConnection API; can even set `Host` headers or conflicting caching
      directives
    - unconstrained TCP connections back to originating host
  - for silverlight: mimicks flash
- attacks against SOP: XSRF, XSS, DNS rebinding
- rules
  - match: (domain name, app layer protocol (http/ftp), tcp port)
  - opt to communicate by setting `document.domain` to same right-hand fragment
    of current host name (eg en.example.com and fr.example.com set to
    example.com)
  - corollary: all subdomains are implicitly granted accessed to parent domain
- workarounds
  - google analytics works by issuing a single-pixel image request containing
    all collected information
  - google maps api works by dynamically creating script tags that load
    on-demand javascript (data can be in JSON)
  - flash: permits cross-domain requests if allowed by crossdomain.xml on
    target webserver
- threat model: defend against impersonation of user and impersonation of site
- some operations still allowed
  - include scripts across domains
  - submit POST forms across domains
- mitigation practices
  - escaping/filtering
  - input validation
  - http responses are variations
  - http request smuggling

ways to do cross-site communication in web apps

- dynamically create script tags to get data
  - unsafe: response can do arbitrary code execution
- Mozilla cross-window messaging via `window.postMessage`
  - receiver gets `message` DOM event; msg contains data, domain, uri, source
  - allows cross-site communication
  - requires explicit msg handling on target page, so less susceptible to
    problems than unchecked shared DOM access (pre-SOP)
- JSONRequest: obsoleted by CS-XHR
  - like form.submit, but no auth data or cookies
- IE XDomainRequest (XDR) and W3C Cross-Origin Resource Sharing (CORS)
  - modern alt to JSONP (but works with reqs besides GET)
  - send `Origin` in req (like `Referer` but no path)
  - require `Access-Control-Allow-Origin` in response; must be `*` or the exact
    page URL
  - CORS is for XmlHttpRequest Level 2, namely the Cross Site-XHR (CS-XHR) part
    (XHR2 bundles many features)
  - IE team criticizes CS-XHR in favor of XDR
  - spec says JSONRequest doesn't address their requirements
- Flash, Silverlight: similar server-side sandboxing as XDR/CORS using
  `crossdomain.xml`
- <http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx>

web application security

- mozilla content security policy (CSP)
  - no inline scripts, only included script files from whitelisted sites
  - no code from strings: eval, setTimeout-with-string, etc.
  - specify where content allowed from/where requests can be sent
  - see examples on <https://wiki.mozilla.org/Security/CSP/Spec>
- html5 sandboxing
  - sandbox tag treats its contents as different-origin
- session attacks to obtain session ids
  - prediction
  - capture
  - fixation: get user to use an attacker-chosen sid
- web application firewalls (WAFs)
  - a type of IDS/IPS
  - modsecurity: for apache; supports negative & positive rule models; has core
    rule set; non-learning
    - very simple rules that give rise to false positives
    - users expected to tweak rules and initially use as IDS only
    - CRS
      - http compliance
      - automation detection
      - owasp top 10 attacks (sql, xss, os cmds, filenames, cf/asp/php, email,
        response splitting, pdf)
      - comm w trojans/backdoors that have already broken in
      - app error hiding
      - external patching

secure javascript

- caja
- secure ecmascript: <http://ses.json.org/>

javascript

- ESAPI: an encoding lib that uses declarative rules and whitelists of allowed
  chars

XSS (cross-site scripting)

- exploits the trust that a user has for a particular site
- name origins: malicious site loads another site in a frame/window, then use
  js to read/write data; blocked by SOP
- now: code (html/js) injection into pages (eg forum) viewed by others (to
  read/write data)
  - frequently: hijack session key; send by embedding in (eg) img url
- types
  - non-persistent aka reflected: request is instantly and transiently used
    (not stored) to return result, eg search engine box
    - only affects the requester, but social engineering (eg send link)
    - most common, but importance is arguable (due to soc eng requirement)
  - persistent aka stored aka second-order: request is stored & later
    displayed (to others)
  - DOM-based aka local: TODO
    - orthogonal to persistence
- 80% of all sec vulns in 2007 -symantec

XSRF (cross-site request forgery)

- exploits the trust that a site has for a particular user
- before SOP, easy for evil.com to use XHRs to send requests to bank.com that
  carry cookies and auth data
- make user's browser send request to a site that user has active credentials
  on
- examples
  - malicious site contains form that entices user to submit
    - POSTs to bank site withdrawing money
    - requires user to be authenticated
  - post img to bank site forum whose src is a GET that (eg) withdraws money
- fixes
  - referer checking: subject to SOP implementation vulnerabilities, but more
    importantly referer-filtering (many enable this for privacy)
  - use nonces to make each http response-http request a challenge-response
    - as long as you use something secret to the outside world, you're fine
    - so you can either generate random numbers
    - or you can use the session ID (or a hash of it to reduce the chances that
      it gets leaked)
    - GET requests are tricky because you can read the URL out of the location
      bar

pluggable authentication module (PAM)

- first in linux (linux-pam from RH), but on other systems now

PKI

- TLS/SSL certificates
  - standard: cheaper, faster; just shows padlock
  - extended: more rigorous issuing policy; also shows company name
  - CAs sell packages: single domain, $n$ domains, wildcard (subdomains)
  - only one https virtual host per IP, since SSL is before the `Host:` header
- SNI: extension to TLS that enables virtual hosting
  - client requests name of virtual domain during TLS nego
- certificate revocation list (CRL)
  - published by the issuing CA on some periodic schedule
  - clients download, cache, check against it
- online certificate status protocol (OCSP): check online if cert still good
  - less BW (don't DL all), real-time
  - impl'd in major browsers
- X509 certificate formats
  - pem: base64, with "BEGIN/END CERTIFICATE"; for DEM certs; originally for
    privacy enhanced mail
  - cer, crt, der: usually in binary DER format
  - p12: PKCS12, may contain both public and private keys; published by RSA
    - protected with password-based symmetric key
    - successor to PFX from MS, criticized for complexity
- renego vulnerabilities: when upgrading an insecure connection to a secure one
  (e.g. STARTTLS) already-buffered plaintext data can slip through
  - attacker can inject prefixes into the data stream
  - eg for HTTP, everything starting from the second GET is from the client
    (and encrypted):

      GET /path/to/resource.jsp HTTP/1.0
      Dummy-Header: GET /index.jsp HTTP/1.0
      Cookie: sessionCookie=Token

MAC and Hashes

- MAC: integrity and authenticity; protect against chosen-plaintext attacks
- message authentication code (MAC): keyed hash; TODO
- message integrity code (MIC): TODO
- hash-based MAC (HMAC)
  - uses 1-way hash (eg SHA), but incorporates shared secret key (for
    authenticity) and re-hashing the hash of the key + message (to prevent
    append attacks)
  - masks key with consts ipad (0x3636..) and opad (0x5c5c..)
  - hmac(key, msg) = hash((key xor opad) + hash((key xor ipad) + msg))
  - <http://dev.ionous.net/2009/03/hmac-vs-raw-sha-1.html>
- cryptographic hash functions: TODO
- diffie-hellman key exchange
  - allow 2 parties w no prior knowledge of ea other to establish shared secret
    key over insecure channel
  - uses discrete logarithm problem: compute discrete logs module an
    appropriate prime (a bit harder/slower than factoring "hard" ints of same
    size)
  - followed shortly by RSA
- secure remote password (SRP)
  - structurally similar to D-H

authentication encryption

- middle option is the only secure one:
  - Encrypt and MAC: encrypt the plaintext, compute the MAC of the plaintext,
    and append the MAC of the pltaintext to the ciphertext
  - Encrypt then MAC: encrypt the plaintext, compute the MAC of the ciphertext,
    and append the MAC of the ciphertext to the ciphertext
  - MAC then Encrypt: MAC the plaintext, append the MAC to the plaintext, then
    encrypt the plaintext and the MAC
- <http://tonyarcieri.com/all-the-crypto-code-youve-ever-written-is-probably-broken>
- <http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html>

- salting: decorating a password (eg prefix/suffix) and hashing that as the
  "password" (for storage/comparison); similar to nonce
  - defends against rainbow table attacks (since each user)
  - variations
    - site-wide, static hash (hardcoded)
    - hash of user info; lacks entropy, still can be predicted (only so many
      usernames)
    - generate and store random salt
    - combo of above: static + user info hash + stored hash

network attacks

- sockstress: syn-synack-ack flood (local iptables configured to not be
  affected)
- ping of death: icmp packet that's >64KB in length
- teardrop: mangled IP fragments with overlapping, over-sized payloads

network reconnaissance

- idle scan aka zombie scan: port scan that doesn't reveal scanner's IP to
  target by using intermediate node ("zombie")
  - attacker sends SYNACK to zombie to get its IP ID (eg 31337)
  - attacker sends SYN to target spoofed from zombie; if port is open, target
    sends SYNACK to zombie
  - zombie sends RST to target since that's what TCP does on unsolicited
    SYNACK; this has IP ID 31338
  - attacker sends SYNACK to zombie again to get its new IP ID 31339
  - if port wasn't open, attacker's subsequent SYNACK would get 31338

anti-IDS HTTP scanning

- libwhisker: Perl scanner with anti-IDS techniques
  - IDSs look for certain things; avoid them
  - GET -> HEAD, URL encoding, double slashes, .. traversal, . traversal, \ on
    Windows, `\0`, case sensitivity on Windows
  - premature request ending: to fool smart IDS systems that try to decode
    too aggressively; `GET / HTTP/1.0\r\n...` -> `GET /%20HTTP/1.0%0D%0A`
  - param hiding: `foo.cgi?...` -> `foo.cgi%3F...`
  - misformatting: eg Apache tolerates tabs in the GET line instead of spaces
  - long URLs to bump off what the IDS scans
  - splice session across multiple packets
  - <http://www.wiretrip.net/rfp/txt/whiskerids.html>

network security tools

- nessus: vuln scanner
- wireshark: packet analyzer
- netcat: swiss army knife
- metasploit: dev framework for exploits
- hping, nmap: network probing
- kismet: wifi sniffer
- tcpdump: packet capture
- cain & abel: windows password recovery
- john the ripper: unix password recovery
- <http://sectools.org/>

IDS/IPS

- snort: network-based; has GUIs (BASE, ACID) built on LAMP
  - requires promiscuous sniffing off ethernet hubs or configure to SPAN
    (Switched Port Analyzer) a switch port via port mirroring
- ossec: host-based
  - file integrity checking, log monitoring, rootkit detection, active response

network hijacking

- TCP hijacking
  - if on same segment: easy to just observe seqno and spoof it
  - if on diff segment: need to guess initial seqno
- IP/BGP/prefix hijacking: take over groups of IPs by corrupting Internet
  routing tables
  - announce a prefix that it you don't actually own
  - announce a more specific prefix than the true owner's prefix
  - announce that you have a shorter route to the target AS
  - "black holing": ??
  - must hijack BGP TCP session
- DNS cache poisoning: tricking NS into thinking it got authentic info
  - specify attacker's choosing of authority NS for either requested domain or
    unrelated domains
  - bugs in eg BIND allowed the above to slip by; now fixed
  - still, no signing means easy to do MITM
  - DNSSEC signs responses with PKI-like infrastructure
- DNS rebinding: trick browser into combining diff hosts into 1 origin
  - circumvent firewalls; access internal sites
  - steps
    - register domain
    - use own DNS server; set short TTL (1s)
    - attract traffic (run ads)
    - serve page w JS that issues another request to domain after TTL (2s),
      triggering DNS query
    - rebind hostname to internal IP (10.10.10.10)
    - send response to attacker
  - DNS pinning: some browsers (IE) cache for add'l min time (30m)
    - still re-queries if can't connect to host
    - hence, after initial page load, firewall off the client; rebind works
- wifi
  - karma: listen for wifi client probes so that you can eg pretend to be a
    familiar AP
  - airdrop-ng: deauthorization tool to disassociate APs and clients
- dhcp exhaustion: silence the orig dhcp server, then become mitm dhcp server
  that dishes out your own gateway, dns, etc; there's a metasploit module
- DNSSEC: includes hashes ('fingerprints') of cert or full cert chain
  - <http://www.imperialviolet.org/2010/08/16/dnssectls.html>

brute-force DOS

- flooding
- DDOS
- easy to detect (? TODO)

sophisticated DOS

- app bugs: eg buffer overflows
- fragmentation of data structures: eg hash tables
- algorithm worst cases, eg regexes

public key crypto

- rsa
- dsa
- elliptic curve
  - attractive for mobile/wireless env's
  - vs RSA: equiv security with smaller key sizes (faster, less resources)
    - use ECDSA

secure ciphers

- rely on bit manip "networks"
  - AES uses substitution-permutation network (SPN)
    - SPN is simplest way to achieve confusion & diffusion; easily implemented
      in HW
  - DES uses feistel network
- Shannon properties
  - confusion: relationship btwn key & ciphertext as complex/involved as
    possible
  - diffusion: redundancy in the plaintext statistics is "dissipated" in
    ciphertext
    - non-uniformity dist in plaintext should be redistributed (somehow)
    - ciphertext bits should depend on input bits in very complex way
    - changing 1 plaintext bit should completely change ciphertext in
      pseudorandom way

block ciphers vs. stream ciphers

- distinction not always clear cut; block ciphers sometimes act effectively as
  stream ciphers
- stream ciphers usu. faster, but serious sec problems if used incorrectly
  (esp: same starting state must never be reused)

stream ciphers

- _stream cipher_: symmetric key cypher where plaintext is combined with
  pseudorandom cipher bit stream called _keystream_, typically xor
  - plaintext bits encrypted one at a time
  - xform varies during encryption
- rc4: by ron rivest; in (eg) WEP, WPA (default), TLS/SSL (opt), BT, ssh (opt),
  RDP, KRB (opt), PDF
- a5/1: in GSM; in US, EU; leaked, rev-eng'd; numerous weaknesses
  - can decrypt GSM phone calls in real time
  - <http://www.schneier.com/blog/archives/2008/02/cryptanalysis_o_1.html>
- a5/2: a5/1 with deliberate weakening for certain export regions

block ciphers

- _block cipher_: operate on large blocks of digits with a fixed, unvarying
  xformation
  - eg 128-bit blocks of plaintext -> 128-bit blocks of ciphertext
- des: early highly influential; ibm; 1997; insecure to brute force
  - EFF DES cracker aka "deep crack": cracking machine
  - with distributed.net, decryted challenge 3 after just 22h
  - controversy over NSA's opaque involvement in design
- 3des: 1998; applies des 3x per block; used by electronic payments industry
  - simply increases key size 3x to defend against brute force
  - pseudocde: des_enc(k1) -> des_dec(k2) -> des_enc(k3)
- blowfish: bruce schneier; 1993; fast; no known cryptanalysis; widely used,
  but aes overshadows it
- rc5: rivest cipher
- AES finalists: RC6, twofish, rijndael, serpent, MARS
- aes aka rijndael: successor to des; 2001
  - 128, 192, 256 bit key sizes; all 128 bit block sizes
- KASUMI aka a5/3 in GSM aka GEA3 in GPRS: no known weaknesses, but GSM is vuln
  (can avoid a5/3)

security status of cryptographic tools

- insecure: MD5, SHA1
- secure: AES, RSA, SHA-2 (SHA-256, SHA-512), SHA-3
- note eg HMAC-MD5 not vuln to MD5 vulns
  - HMAC strength depends on secret key len
  - brute force is most common attack; less affected by collisions than
    underlying hash fns alone

cryptographic hash fns

- SHA: NIST-approved
  - SHA-3: SHA-3-512
- blowfish: bruce shneier
  - expensive key setup phase

crypt

- uses hash fn, encodes salt, records which hash fn used
  - by default, uses DES on data=0, key=truncated pass
  - other versions exist that use md5, blowfish, sha
- eksblowfish (provos, mazieres, 1999)
  - take adv of expensive key setup phase of blowfish
  - introduce configurable # rounds to make validation arbitrary expensive

block cipher modes

- insecure: electronic codebook (ECB)
- output feedback (OFB), cipher feedback (CFB), counter (CTR)
  - don't repeat _initialization vector (IV)_ for same encryption key
  - turns block ciphers into self-synchronizing stream cipher
  - CFB: identical to CBC encryption done in reverse
  - OFB: gen keystream blocks that are XORed w plaintext blocks
- cipher block chaining (CBC), propagating CBC (PCBC)
  - each plaintext block XORed w prev ciphertext block before encryption
  - encryption sequential, but decryption *can* parallelize
  - PCBC: also XOR the prev plaintext block
  - use this if msg authenticity is not an issue
- authenticated encryption (AE): simultaneously protect confidentiality and
  integrity
  - AE with associated data (AEAD): block cipher modes
  - CCM, CWC, OCB, EAX, GCM

programming

- don't use expert interfaces: OpenSSL, Crypto++, CommonCrypto, CryptoAPI, etc
- use NACL, keyczar if you really need crypto
- otherwise try using PGP/GPG for data-at-rest or TLS for data-in-motion

VPNs

- point-to-point tunneling protocol (PPTP): microsoft's default VPN
  protocol
  - remains popular
  - protoco-independent, but main usage: TCP control stream, GRE data stream
    (many firewalls don't support GRE)
  - there are alts eg RADIUS but PPTP is default for client back-compat
  - doesn't require PKI, unlike L2TP/IPsec
  - provides confidentiality, not integrity or authentication
  - encapsulates PPP
- layer 2 tunneling protocol (L2TP)
  - derived from PPTP
  - combines control & data channels
  - protocol-indep, but mainly used over UDP 500
  - standards bodies attn shifting toward L2TP from PPTP
  - uses IPsec ESP by default
  - also provides user auth
  - encapsulates PPP
- IPsec
  - provides confidentiality, integrity, authentication
  - uses PKI and machine-level certs
  - doesn't provide user auth
  - TODO
- secure sockets tunneling protocol (SSTP): tunnels over HTTPS (TCP 443)
  - provides confidentiality, integrity, authentication
  - encapsulates PPP
- IKEv2: uses IPsec
  - provides confidentiality, integrity, authentication
  - supports the latest ipsec encryption algos
  - supports mobility (MOBIKE); resilient to changing network connectivity; can
    switch APs or even wired/wireless
- OpenVPN ALS: web-based SSL VPN server written in Java; derived from Adito,
  SSL-Explorer
  - provides in-browser HTTPS client access with java applets for tunneling
- misc
  - PPTP, L2TP, SSTP depend heavily on features orig for PPP
  - built in to windows: PPTP2, L2TP/IPsec, SSTP, IKEv2
  - SSTP, IKEv2, maybe others: don't require client-side PKI deployment or pre-shared key
  - SSTP, IKEv2, maybe others: integrate well w EAP
- refs
  - <http://www.intranetjournal.com/foundation/tunneling.shtml>
  - <http://technet.microsoft.com/en-us/library/dd469817(WS.10).aspx>
  - <http://blogs.technet.com/rrasblog/archive/2009/02/10/do-we-still-need-pptp-l2tp-ipsec-after-windows-7.aspx>

authentication protocols

- EAP
  - authentication framework, not specific mechanism; over 40 methods
  - used in wireless networks and point-to-point conns
  - adopted by WPA, WPA2
- challenge handshake authentication protocol (MS-CHAPv2)
  - the only authentication protocol for windows PPTP
  - uses DES
  - weaknesses known by 1999; bruce schneier and l0pht wrote a
    cryptanalysis
  - username is in plaintext
- lightweight extensible authentication protocol (LEAP): cisco-proprietary
  extension of EAP; in cisco ap's
  - uses modified version of MS-CHAP
- newer: EAP-FAST, PEAP, EAP-TLS
- EAP-TLS: TODO
- u-prove: maintain privacy while proving that i can pay
  - TODO can't tell if same person made txns?

wifi

- WEP: can be sniffed by any user
- WPA/WPA2: diff link key per user, unless they can capture initial handshake
  - pre-shared key (PSK) means this link key can be recovered trivially from initial handshake
- <http://serverfault.com/questions/149888/wep-wpa-wpa2-and-wifi-sniffing>

windows security

- 2 ways windows stores acct credentials: LAN Manager and NTLM
  - LAN Manager: weak; brute force, rainbow tables
  - NTLM: time-memory tradeoff attacks

cracking techniques

- brute force
- rainbow tables: sets of precomputed hashes as a time-memory tradeoff

cracking tools

- MS-CHAPv2, LEAP, PPTP
  - ASLEAP: cracks LEAP and PPTP; updated to crack MS-CHAPv2
    - given MS-CHAPv2 challenge and response, return last 2 bytes of password
      hash (username already in plaintext)
  - CUPP: common user password profiler; wizard-like dictionary generator
    that asks for info about user
  - genkeys: generates hashes of a wordlist using DES
  - cowpatty: cracks pre-shared key (PSK) WPA networks based on the TKIP
    protocol
- MD5
  - BarsWF: CUDA-based MD5 cracker; 4B hashes/s with quad SLI;
    <http://3.14.by/en/md5>
- windows: LAN Manager, NTLM
  - pwdump: outputs LM and NTLM account password hashes from the Security
    Account Manager (SAM)
  - CUDA-based NTLM brute forcer for linux:
    <http://3.14.by/forum/viewtopic.php?f=8&t=60&>
  - ophcrack: crack windows passwords using rainbow tables
  - usbophcrack: downloads some rainbow tables and creates boot usb
    - advise using ophcrack's rainbow tables instead
- <http://revision3.com/hak5/asleap>

windows system security

- ASLR
- DEP: uses NX if avail or software emulation with limited, almost-unrelated
  protection with SafeSEH (simply checks that an exception is registered in a
  function table for the app)
- common exploit techniques TODO <http://www.hick.org/~mmiller/shellcode/win32/generic.c>
  - PEB
  - SEH
- steadystate/pc safeguard
  - applied only to std accounts; rolls back all reg, fs changes

windows 7 UAC design flaws

- auto-elevating executables: to reduce annoyance
  - but anyone can run them; at one pt rundll32 was auto-elevating
- auto-elevating components
  - work only when caller is ms-signed exe, eg explorer
  - but procs can inject code into ea other as long as same user
- <http://arstechnica.com/microsoft/news/2009/03/opinion-ms-should-kill-win7-uac.ars>

selinux (nsa 2000; merged mainline 2003)

- supplements unix DAC with MAC
- selinux is an implementation of FLASK for linux
- hybrid of concepts and capabilities from MAC, MIC, RBAC
- hard to config
- applies labels to files
- identifies files by inodes
- perms
  - specify specific ops (creat, rename, unlink, etc)
  - allow, deny, auditallow, auditdeny

linux apparmor (novell 2005)

- supplements unix DAC with MAC
- manually specify profiles for apps
- "learning mode" logs holes that are opened and creates profiles from that
- alternative to selinux
  - identifies files by paths instead of inodes
  - can make use of FSs with no support for extended file attributes, eg NFS

SFI
---

TODO

efficient software-based fault isolation (wahbe, sosp93)

- [aka "classical SFI"]
- isolate software modules without relying on MMU
- naive custom compiler approach: on a write or indirect branch/jump, check that addr is in current module's range
  - slow
  - circumventable; eg, indirect branch to own write that skips the checks before it
- use a dedicated reg to hold an addr
  - all writes must be performed to the addr in the reg
  - reg must always point to valid addr in current module
    - if any instr invalidates this, program must fail or fix by the next write/indir jump
- to jump outside, use local jump table; system allows only this table to point outside
  - allows indir jumps to be very simple: only check for local
  - switch stacks
  - callee-save regs: call stub saves regs in case callee does not preserve regs
- opts
  - checks can be made into a simple bitmask as long as ranges can be identified by bit prefixes
  - stack writes use $esp + small static offsets; hence just validate $esp when it's changed, and pad module space with guard regions that are bigger than biggest offsets
- overhead: 0-12% (avg 4.3%); if also checking reads, avg 21.8%
- [depends on large trusted compiler for correctness; later works like pittsfield use smaller verifier on machine code]
- [not used in practice, maybe bc depends on RISC features like reserving certain regs, maybe bc no robust product]
- [pittsfield, vx32 apply to x86 and have more robust prototypes]
- [vx32 creatively exploits legacy hardware being phased out]
- [SFI has a useful fault iso model that deserves HW support]
- <http://papersincomputerscience.org/2009/12/19/efficient-software-based-fault-isolation/>

pittsfield (stephen mccamant, greg morrisett, TR/usenix 2005)

- SF vs pittsfield: write/jump sandboxing vs full read/write/jump isolation

vx32 (bryan ford, russ cox, TR 2008)

- x86, linux/freebsd

linux containers (lxc)

- can evade lxc as root in lxc by eg sysfs <http://blog.bofh.it/debian/id_413>
  - will be fixed upon support for labeling files with user namespaces
- user namespaces: allow normal user to unshare namespaces
- The most glaring reason is that user namespaces are not yet being enforced at
  most user id comparisons, including at file system.  That means that user id
  X in one user namespace will be deemed owner of a file created by user id X
  in another user namespace. Toss in root and virtual filesystems like /proc
  and /sys, and root in a container can do what he likes with the host. MAC can
  help mitigate this, but user namespaces are still being developed to provide
  the real solution.
- Another reason, fwiw, is simply that it shares the same kernel as the host.
  So any exploits in any system calls can likely be exploited by the container
  to gain privilege and escape the host. The worst offenses are usually in
  newer system calls, so some hope is being placed in seccomp2 to mitigate this
  concern.
- <http://s3hh.wordpress.com/2011/05/31/escaping-chroots/>

engineering
-----------

<http://www.matasano.com/log/989/thoughts-on-ten-years-of-qmail-security/> (DJB 2007)

- directions of progress
  - eliminating bugs
  - eliminating code
  - eliminating trusted code
  - distractions
    - chasing attackers
    - minimizing privilege: vs minimizing TCB
      - ["privileges" here are superficial OS level privileges]
    - speed
- eliminating bugs
  - enforcing explicit data flow: process isolation, PL support
  - simplifying integer semantics: used big num lib, PL support
  - avoid parsing: anything with strings; quoting; printf bugs
  - generalizing from errors to inputs: insert testable abstractions
- eliminating code
  - identifying common functions
  - automatically handling temporary errors [exceptions better than error checking]
  - reusing network tools [like `inetd`]
  - reusing access controls: eg assuming a user's uid
  - reusing the file system: as an associative array (instead of parsing a
    single config file)
- eliminating trusted code
  - accurately measuring the TCB: hard
  - isolating single-source xforms
    - eg jpegtopnm: after jailing, attacker can only produce any img he wants,
      but he could've done this in the first place
    - sandbox recipe
      - Prohibit new files, new sockets, etc., by setting the current and
        maximum RLIMIT_NOFILE limits to 0.
      - Prohibit filesystem access: chdir and chroot to an empty directory.
      - Choose a uid dedicated to this process ID. This can be as simple as
        adding the process ID to a base uid, as long as other
        system-administration tools stay away from the same uid range.
      - Ensure that nothing is running under the uid: fork a child to run
        setuid(targetuid), kill(-1,SIGKILL), and _exit(0), and then check that
        the child exited normally.
      - Prohibit kill(), ptrace(), etc., by setting gid and uid to the target
        uid.
      - Prohibit fork(), by setting the current and maximum RLIMIT_NPROC limits
        to 0.
      - Set the desired limits on memory allocation and other resource
        allocation.
      - Run the rest of the program
  - delaying multi-source merges (like XSS)

practical sandboxing

- chroot etc
  - can escape as root, or else re-chroot, inject modules, ptrace non-chrooted
    procs, etc
  - sensitive to TOCTTOU
    - disallow clone() with CLONE_VM, prevent creating writeable MAP_SHARED mem
      maps (or at least track them)
    - alternatively SIGSTOP/SIGCONT all processes in traced group
    - <http://stackoverflow.com/questions/4414605/how-can-linux-ptrace-be-unsafe-or-contain-a-race-condition>
- ptrace (systrace, sydbox, pinktrace, libsandbox, etc)
- lxc: a better/more general chroot
  - (until user namespaces implemented) can escape as root
  - new namespaces: pid, network, ...
- resource limits
- seccomp: too restrictive (can't even alloc mem)
- seccomp-bpf: can't deref ptrs, only raw syscall args
- lsm: don't stack
  - selinux/apparmor: administrative, heavyweight
  - smack: simpler, uses hybrid inode/path identification
- privsep: use diff processes, UIDs, w min privs
- openvz: not avail in stock ubuntu 12.04
- <https://www.cr0.org/paper/jt-ce-sid_linux.pdf>

web
---

robust defenses for CSRF (adam barth, collin jackson, john c mitchell, CCS 2008)

- login CSRF
- TODO

sound and precise analysis of web applications for injection vulnerabilities (ucdavis, pldi07)

- prev static approaches use tainted information flow tracking
  - don't model precise semantics: even 'sanitizers' like `escape_quotes` could
    fail to sanitize inputs
  - require manual specifications bc systems don' track string value sources
  - not fully automated and may require user intervention at various points in
    analysis
- consider as attacks those queries for which user input changes the intended
  syntactic structure of the generated query
- implemented for PHP; analyzed large (100KLOC) progs; few false positives

DOS
---

<http://www.checkmarx.com/NewsDetails.aspx?id=23> regex ("redos")

- worst-case exponential
- eg: /^(a+)+$/ on "aaaaX" produces 16 paths
- more: /([a-zA-Z]+)*/, /(a|aa)+/, /(a|a?)+/, /(.*a){x}/ for x>10
- many legit bad regexes even in OWASP validation regex repo
- many pts of attack; regexes are ubiq
  - submit a bad regex or leverage regex injection
  - submit a string for an already-there bad regex
- meta-regex for finding bad regexes; use codesearch to find
- browsers protect against infinite loops but not bad regexes
- should be not-too-bad to statically analyze regexes

fun exploits
------------

morris worm

mark dowd flash exploit 2007

- <http://chargen.matasano.com/chargen/2007/7/3/this-new-vulnerability-dowds-inhuman-flash-exploit.html;jsessionid=8DDE25A54184976447838948127BE85C.web18>
- bounds-checker treats field as signed, permitting (small?) negative numbers
- interpreter treats as unsigned, so neg -> large
- controls alloc, so bad alloc -> null ptr
- flash uses that ptr + attacker-controlled offset
- to that addr, flash writes attacker-controlled value
- idea: use this writing vector to target a function ptr, changing it to a
  user-supplied buffer of shellcode
- tough constraints: offset > 0x80000000, offset + 4 divisible by 12, used
  value = (value cast from 16- to 32-bit) - some other var
- so instead, manipulate actionscript bytecode state
- interpretation differs btwn verifier TOC & executive TOU
  - verifier ignores undefined bytecodes
  - verifier keeps table defining bytecode instruction lengths
  - bytecode length table is valid target of null ptr overwrite
  - executive has totally diff machinery for interpreting bytecode
- use null ptr write vector to clobber the right value in length table, and you
  can make unused instr that the verifier ignores seem much longer than it is
- executive doesn't ignore what comes after the initial unused instr, so put
  valid bytecode there for execution

kernel null pointer exploits

- tun driver uses null ptr; can write to 0x0 with mmap, iff selinux is on,
  ironically
- ptr is used in an exploitable way
- "In well-designed systems, catastrophic failures are rarely the result of a
  single failure. That is certainly the case here."
- <http://lwn.net/Articles/342330/>

IFC
===

general

- [autoescape makes taint mode obsolete for web apps?]

taint mode for python via a library (2010)

- dyntaint: nifty; only does basic taint
- decorators: @untrusted, @ssink(TYPE), @cleaner(SQLI) where TYPE denotes
  channel type with relevant attacks (SQLI, OSI)
- <http://www.juanjoconti.com.ar/2010/07/06/talk-taint-mode-for-python-via-a-library-slides/>

RESIN: Improving Application Security with Data Flow Assertions (alex yip sosp09)

- python-taint: alexyip; requires new interpreter
- _filter objects_ define data flow boundaries on functions, IO channels
  - eg file objects, escape()
  - default set on all standard libs
  - eg filter on http output channel could check for attacks like crlfcrlf
- annotate sensitive data w _policy objects_
  - export_check(ctx) method checks that ctx is suitable to output data to
  - eg for passwd
    - policy object has an email field
    - export_check(ctx) = ctx is email to matching recip, or ctx is http to admin
  - eg user supplied inputs
  - merge(policy_set) method is overridable; defaults to union
- runtime tracks ints, strings (possibly down to individual chars)
  - wraps sql db interfaces to persist policies (rewrites schemas)

DIFC
----

flume

- IFC goals
  - secrecy: prevent leaking private data
  - integrity: prevent accepting untrusted data
- DIFC: decentralized means no central deputy needed for declassification
- flume: DIFC at process granularity, controlling IO; user-level monitor
- related work
  - jif: finer-grained control at function granularity; requires app rewrite
  - asbestos/histar: kernels designed to support DIFC; message granularity
  - flume
    - rules inspired by jif
    - labels influenced by asbestos
    - adopted histar's requirement that threads must explicitly request label changes
- concepts
  - a tag $t$ is associated with some category of secrecy or integrity
  - labels are sets of tags
  - a process $p$ has 2 labels, $S_p$ for secrecy and $I_p$ for integrity
    - if $t \in S_p$ then (conservatively) $p$ saw private data tagged with $t$
    - if $t \in I_p$ then every input to $p$ has been endorsed as having
      integrity for $t$
  - two capabilities per tag
    - $t+$: ability to add $t$ to one of its label
    - $t-$: ability to remove $t$ from one of its label
    - note: you might not want to use the same $t$ for both secrecy and
      integrity; see examples below
  - each $p$ owns a set of capabilities $O_p$
  - $D_p = { t \vert t+ \in O_p, t- \in O_p }$ (the set of tags for which $p$
    has dual privileges)
  - any $p$ can create tags; added to $D_p$
  - global capability set $O \subseteq O_p \forall p$
- export protection example
  - if $b \in S_p$ then $p$ can write to $q$ iff $b \in S_q$ also
  - but _any_ process can add $b$ and read secret $b$ since $b+ \in O$
    - means all their output will be tagged with $b$
    - note that this means $b$ should not be used for integrity, or anyone can
      add it to their integrity label
  - but a process $p$ can't leak it out of system unless $b- \in O_p$
    - transition: from secret to non-secret
- integrity protection example
  - if $b \in I_p$ then $p$ can read from $q$ iff $b \in I_q$ also
  - processes cannot willy nilly add $b$ and be trusted to provide $b$-tagged
    data
    - transition: from non-trusted to trusted
    - this is called _endorsement_
  - can, however, remove $b$ to remove trust (not sure why they want to do
    that); so $b- \in O$

IE

- Protected Mode for isolation and sandboxing
- type 1 (reflected) xss filter

malware
-------

the ghost in the browser: analysis of web-based malware (provos, google, 2008)

- 10% of URLs engaged in drive-by downloads
  - map-reduce looks for known malicious URLs in corpus
  - instrumented IE in VM; watch for add'l processes, changes in FS/reg
- malware comes from lack of content control on pages
  - web app exploits
  - user content
  - ads: partner with dedicated ad companies, not individual advertisers; trust
    is not transitive
  - third-party widgets: eg stats counter, iframemoney.org
- exploits
  - popular: MS DAC
    - js instantiates activex object; normally not safe for scripting
    - js retrieves exe via XHR
    - adodb.stream used to write exe to disk
    - shell.application launches new exe
  - popular: MS WebViewFolderIcon heap spray
  - many gather info (eg browser, jvm version, OS patches) then fetches
    applicable exploits
  - can also trick user, eg video activex codec
- trends
  - js escaping: effective against signature/anomaly-based IDSs; also used by
    legit sites
  - classification: use majority voting by major AV software
    - trojan: contains/installs malicious app with harmful impact on user's
      computer
      - most common: downloaders (get other trojans), banking (bank acct
        numbers, passwds)
    - adware
    - unknown/obfuscated
  - http reqs not from browser: mostly for popup ads, some for updates/instrs
  - most exploits not hosted on compromised sites; distributed across many
    sites
  - hosted binaries mostly change infrequently; some do, to evade sig scans
- most malware are user-mode apps
- [curiously, saw nothing on spam]

a crawler-based study of spyware on the web (uw, 2007)

- downloaded exe's, ran/install in VM, ID with lavasoft ad-aware
- twice: 5/2005, 10/2005
- high risk sites: games, celebs
- types
  - adware
  - keylogging spyware
  - trojan downloaders
  - browser hijackers: search engine, default home page, URL redirection
  - dialers: uses modem to call expensive toll numbers
  - mostly adware, hijackers (relatively benign) but many downloaders
  - drive-by's have same distribution as spyware
- time comparisons: older AV DB misses 1/3 of spyware; URL blacklisting
  ineffective [numbers don't seem to support, though]
- many tweak registry
- collection via disposable webmail
- [notes]
  - curiously, saw nothing on spam, game passwd harvesting
  - no need for exploits

systems security
----------------

return-oriented programming (Hovav Shacham, ucsd, 2009)

- generalization of return-to-libc; chain `ret`s together
- [not much here]

"Countering Kernel Rootkits with Lightweight Hook Protection"

- gist: copy all hooks to read-only mem and make all callsites (found by
  profiling) use that
- premise: preserving kernel code integrity (eg disallowing changing kernel
  code and disallowing introduction of new code) is not enough
  - exploits leverage existing code and subvert control flow, eg return
    addresses and function pointers
  - protecting return addresses is well studied
  - this paper: protecting function pointers (hooks)
- profile system offline to find out the calling sites of all hooks, or _hook
  access points (HAPs)_
  - given the list of kernel hook locations for protection (globals)
  - dynamically allocated hooks: discovered at runtime by monitoring call stack
    at alloc sites to see what object is being created
- online system protection: run OS in hypervisor (Xen)
  - after OS init, copy all hooks into a memory region; these copies are the
    _shadow hooks_
    - region is read-only
    - read/write requests distinguished by HAP
    - hypervisor validates write request (requires new hook value to be
      recognized from offline profiling phase, but other validations possible)
  - dynamically allocated hooks: alloc/update/free results in hypercall
  - memory protection is guaranteed by hypervisor shadow page table
  - trampoline the HAPs to call into shadow hook area
    - (as typical) the instructions are in read-only executable text pages
  - syscall table can be uniquely optimized

seminal
-------

Why Isn't Trust Transitive? (bruce christianson, william s harbison)

- straightforward but classic

Sandboxing
----------

privsep (niels provos, usenix 03)

- privileged parent monitor and unprivileged child process
- no syscall tracing; only using OS UID-based privilege separation
- child runs with unused user and chroot'd to /var/empty
- comm over pipes, shared mem

Efficient Software-Based Fault Isolation (Wahbe, sosp93)

- can isolate via separate addr spaces, but switches not good for tightly
  coupled modules
  - RPC: trap, copy, ctx save/restore, switch HW addr space (flush TLB), trap
    - repeat on return; 3 OOM > normal proc call
  - eg postgres extensible type system can define ctors, dtors, preds
  - eg OS exts: packet filters, app-specific virt mem mgmt, Active Messages
- propose a portable, PL-indep approach:
  - load code/data into own _fault domain_ (portion of host's addr space)
  - rewrite code to prevent writes/jumps outside fault domain
- poses tradeoff rel. to hardware fault isolation: substantially faster comm
  btwn fault domains, but slightly increased execution time for distrusted
  modules
  - evaluated on postgres; 3x faster than sep addr spaces

App-V (john sheehan, MS ECS 2009)

- _sequencing_: process of packaging apps
  - monitor installation from kernel; capture FS/reg changes
  - now know all the resources needed by app; can optimize the layout for
    streaming
  - extract metadata; eg recognize COM objs, NT services; store in manifest
  - heuristics
    - program files: don't need to roam with user
    - hkey_current_user keys: should roam with users
    - UI for tweaking these settings
- SystemGuard: "namespace mgr"
  - system namespace: fall-through for everything else
  - elseapp namespace: produced by sequencing
    - eg `C:\windows\system32\foo.dll` could've been installed by app
    - enables streaming (Click2Run), user roaming
  - modification namespace: where writes go (either roaming or non-roaming)
  - handles: files, reg, COM, fonts, services, object mgr, mailslots, etc.
    - eg virtualize CLSIDs for COMs; virtualize service names
    - don't deal with drivers; typically installed as part of platform
  - dynamic, not static: watch processes, not programs
    - eg cmd is already there, but if run via a VS shortcut, run it in the VS
      bubble
  - for cross-app, dynamic suite composition (DSC) feature: run in same bubble
- office doesn't user the generic app-v UIs

native client

- inner sandbox
  - software fault isolation
    - in general disassembly is unreliable: same instruction stream may be
      entirely different if you jump to somewhere in the middle of it
    - goal: get reliable disassembly; then, can prohibit certain instructions
    - static validation of most calls/jumps
    - once loaded, binary is not writable; also uses x86 segments to constrain
      the executable instruction range
    - locates instructions at address 0 so that indirect jumps need only be
      prefixed by an `and` and not an `and;or`
    - omit certain instructions: ret, int, syscall; use indirect jumps
    - all indirect branch targets must be aligned; bitmask every target
      address
    - no code gen, mixed text/data, overlapping instrs
  - x86 segments: hardware support -> faster
    - original SFI: bitmask every load/store address
    - caveat: need LDT; privileged instruction, vista 64 doesn't provide this;
      confuses os an hardware exceptions
- outer sandbox
  - redundant; defense in depth
  - system call filter for untrusted modules
  - OS-dependent: ptrace on linux, syscall ACLs on Windows
    - to avoid ptrace overhead, nacl provides own shared mem and sync objects
- compile for native client with modified gcc (1000 lines patched)

Sprockets: Safe extensions for distributed file systems (umich usenix 07)

- for distributed FS "tweak" extensions; DFSs mostly impl'd in user space
  - run procedure in same addr space, then always roll back except for the
    buffer expecting results (this is validated/acted on by host)
  - programmability like proc call: lightweight usage, can access any data/code
  - cost: not up front per sprocket, but per line of code executed, since
    sprockets are small
- alt designs and their problems
  - direct procedure call: same addr space
  - separate addr spaces, eg fastcgi
    - no access to (reuse of) data/code; need to define (read) interface
    - requires OS fine-grained sandboxing (only read file1 and write file2)
  - chkpt/rollback (fork): closest to sprockets
    - heavy; still requires OS sandboxing
    - idea for multithreading: wait for all locks to release before fork
- binary instrumentation/SFI with PIN
  - first save caller ctx (regs, PC, heap size, etc)
  - for each mem write, save orig loc/val in undo log
  - dynamically enable/disable instrumentation: core FS functions called via
    sprockets are instrumented; outside, orig is used
  - OOM slower, but faster than fork
  - optims: no need to restore unused memory, eg space below stack or malloc'd
    by sprocket; avoid dup backups
- handling buggy sprockets
  - register sig handlers for segfaults, timeouts
  - instrument syscalls with check against whitelist + optional specific
    syscall handling (eg closing an fd that it didn't open)
- multithreading: sprocket time (.14-.62ms) << scheduling quantum
- implemented: transducers (id3), app-specific resolution (id3), devices (PTP)
- related work
  - wahbe: limits access to addr space outside sandbox
  - vino: SFI for OS exts; not full access (whitelist of kernel fn's)
  - nooks: used this technique for device drivers
  - exokernel: allows user-level code to impl many services
  - sprockets target functionality already avail. at user-level; min changes;
    user-level tools/libs
  - type-safe langs: eg SPIN OS uses modula-3; limits FS code reuse (mostly not
    in type-safe langs)
  - watchdogs, stackable FSs: more coarse-grained ext interface allowing exts
    only at certain pre-defined VFS ops like open, close, write
  - may leverage STM/HTM techniques

Saltzer & Schroeder, "The Protection of Information in Computer Systems"

- seminal paper on OS security
- no mention of pub key crypto; still 5 yrs away

chrome/chromium

- chroot: requires suid but is ironically more secure
- exec()ing from empty jail is hard
  - can copy all dep files, but maintenance/packaging nightmare
  - use clone() flag CLONE_FS and share FS struct btwn a trusted/privileged
    thread and the exec()ed renderer
  - trusted thread can call chroot and have it affect the unprivileged,
    untrusted renderer post-exec
- CLONE_NEWPID and CLONE_NEWNET: prevent sending signals, network access
- <http://scarybeastsecurity.blogspot.com/2009/10/chromium-and-linux-sandboxing.html>

Security In-Depth for Linux Software: Preventing and Mitigating Security Bugs (Julien Tinnes, Chris Evans, Google, Hack in the Box 10/2009)

- examples: chromium, vsftpd
- security in depth
  - reduce bugs
  - app-level mitigation (SSP, relro)
  - sys-level mitigation (ASLR, NX)
  - privilege dropping (sandboxing)
  - mandatory access control (MAC)
  - update strategy
- privileges in linux: processes and privileges
  - kernel is a mandatory interface to system; process is privilege boundary
  - A > B if A's privileges are superset of B's
  - procs have uid + gid
  - threads *generally* don't have privilege separation (but: clone, seccomp)
  - if A can ptrace B, then A > B
  - uids/gids
    - types
      - real: owner; who you really are; only root (usu. login) can change; `id -ru`
      - effective: for access ctl; `id -un`
      - saved: 
      - FS: file system; in linux
    - operations
      - fork inherits UIDs
      - suid + seteuid let you temporarily drop root and restore later
      - not sure if correct (prolly not):
        - `setuid(x) = if (euid == 0) { ruid = euid = suid = x } else { euid = x }`
        - `seteuid(x) = if (euid == 0) { ruid = euid = suid = x } else { euid = x }`
    - summary
      - (r)uid, euid, suid, fsuid
      - (r)gid, egid, sgid, fsgid, supplementary groups
  - POSIX.1e capabilities: for splitting root privileges; in linux 2.2
  - partial uid switching
    - mostly useful to avoid confused deputy problems
    - useless given arbitrary code execution
    - only root can use
  - linux capabilities
    - CAP_NET_RAW: permit use of RAW and PACKET sockets
    - CAP_SYS_ADMIN: administrative ops (mount, sethostname, etc)
    - CAP_NET_BIND_SERVICE: binding to reserved ports (<1024)
  - common mistakes
    - forgetting to switch from uid 0
  - chroot: popular way to drop FS access; root only
    - requires dropping privileges afterward, or easy to escape
    - re-chroot technique (popular), inject modules, ptrace non-chroot-ed proc,
      etc
    - look at capabilities for inspirations of other things you can do as root
      to escape
  - recent kernels add clone/unshare flags for dropping privileges; root only
    - CLONE_NEWPID: new pid namespace
    - CLONE_NEWNET: new network namespace
    - CLONE_NEWIPC, CLONE_NEWUTS, CLONE_NEWNS
  - resource limits
    - RLIMIT_NOFILE: can't get new fd's, but can still rename and unlink
    - RLIMIT_NPROC: can't create new procs
    - if used for security, both soft and hard limit need to be set to 0
    - or attacker could replace existing fd to create new fd's
  - linux supports per process dumpable (debuggable) flag
    - can be set through
      - prctl with PR_SET_DUMPABLE
      - when executing a file you don't own and can't read
      - when switching uid
    - CAP_SYS_PTRACE: can't ptrace a non dumpable proc; thus, elevation of
      privileges
    - allows to lower another process' privileges
- writing good code
  - preventing common security flaws
  - privilege separation
  - trust relationships
  - update strategy
- sandbox designs
  - ptrace
    - slow
    - nacl paper reports many CVEs; very buggy area
    - many pitfalls (TOCTTOU)
    - highly sensitive to exact kernel/glibc version/arch
  - setuid helper: use root to chroot, set resources, preven ptrace/signals
    - require administratively defined pool of UIDs/GIDs (no /etc/passwd
      entries)
    - on invoke, switch to unused UID/GID (atomically; use RLIMIT_NPROC to make
      setuid fail if uid alraedy used)
      - partition the pool among UIDs to prevent user from exhausting pool
      - UID switching alone not enough: /tmp, setuid binaries
    - to execve after chroot
      - naive: mustn't give CAP_SYS_CHROOT
      - realistic: don't use execve, mmap the code; inconvenient/dangerous but
        realistic
      - optimistic: give another proc the priv to chroot us to empty dir
        - routine
          - sandbox proc A spawns B
          - use clone w CLONE_FS so A & B share a root dir, cwd, etc
          - A drop privs, B waits for msg from A
          - when A wants to chroot, send msg
          - B chroot to empty dir, which also affects A
        - a root proc B shares FS w untrusted proc A; scary, drugged deputy?
        - mitigations: B can drop caps too, all but CAP_SYS_CHROOT, set
          RLIMIT_NOFILE to 0,0
    - drop UID/GID pool range?
      - not changing UID & switching to a single common GID
        - prevent ptrace from a sandboxed proc to another proc
        - PR_SET_DUMPABLE prevent ptrace among sandboxed proc
        - signals?
      - using a new PID namespace (CLONE_NEWPID)
        - solves many problems
        - how secure?
    - drop net access
      - use RLIMIT_NOFILE, but what if need new FDs? share (using CLONE_FILES)
        w a broker proc
      - CLONE_NEWNET: cut access completely
    - conclusion: chromium renderer runs in this sandbox (first-level sandbox)
  - SECCOMP
    - read, write, exit, sigreturn
    - too limited: no mem alloc (mmap, brk), no new FDs (recvmsg)
    - trusted thread: each seccomp'd thread has trusted helper thread for
      syscalls
    - trusted code in RX only mem
    - prevent trusted code from accessing volatile mem by...
      - use pure asm, can't use stack
      - but some syscalls pass ptrs to volatile mem (open)
    - for access to volatile mem, use sep trusted proc that shares pages (TT
      can only read)
    - high potential to isolate kernel but still WIP, perf issues, disabled
  - other
    - rely on a MAC
    - lack of discretionary priv dropping facilities
    - recent efforts: LSMSB, selinux type boundaries, ftrace
    - virtualization
  - attack surface eval

Xax (MSR)

- mechanisms
  - picoprocess: native-code execution abstraction that is secured via hardware
    memory isolation and a narrow syscall interface, akin to streamlined
    hardware VM
  - PAL: provides an OS-indep ABI to xax picoprocesses
  - hooks to existing browser mechanisms to provide aps with system services
    (network, UI, storage) that respect browser security policies
  - lightweight modifications to existing tool chains and code bases for
    retargeting legacy code to the xax picoprocess env
- goals and alternatives
  - goals: security, OS indep, perf, and legacy support
    - [they compare SF LOC of C/C++ vs. others; this disregards verbosity, the
      projects themselves, etc.; may have been better to count number of
      projects]
  - alternatives
    - existing web-app mechanisms
      - js: slow; no legacy code
      - activex: no sandboxing; only a way to package app for invoking via web;
        windows only
      - IL (flash/java/MSIL): no legacy code
    - OS processes: not OS indep, insufficient sec
      - can write interposing confinement layers, but that's hard
      - xax goes opposite: start with no interface and add
    - hardware vm's: big/complex, so slow dl, insecure, hard to write
      - xax = extreme paravirt where guest os is removed
      - reduces vmm also: no emulation of devices, mmu, cpu kernel mode
- mechanisms
  - picoprocess: VM without devices, MMU, CPU kernel mode
    - alternatively, a highly restricted proc prevented from making kernel calls
    - hardware-memory-isolated address space; strictly user-mode CPU
    - xax monitor: browser plugin; picoprocess makes xaxcalls to this
    - xaxcalls vary slightly among platforms to keep xax monitor simple
  - platform abstraction layer (PAL) for OS indep
    - PAL translates OS-indep ABI to OS-specific xaxcalls
    - PAL runs inside picoprocess; untrusted; everything above ABI is remote
    - only 9 calls in xax abi
    - simple shim libxax that converts app dev toolchain's calling convention
      into xax ABI calls into PAL
  - services via browser mechanisms: same security policies
    - picoprocess is web server; serves http requests
  - lightweight code modification: 5 steps to addressing all porting issues
    - TODO
    - obliviously failing
    - emulate syscall functionality internally
      - eg fs: read from tar, write to ramdisk; also read from other files, eg
        downloaded from server
    - provide real syscall functionality via xaxcalls
      - real backing functionality for remaining 137 syscalls (11 unique)
- implementation
  - monitor, boot block, PAL
    - monitor is its own process; xaxcalls via shared mem
    - boot block sets up shared mem, makes kernel call to revoke ability to make subsequent kernel calls, and continues into PAL (which loads/executes app)
    - most xaxcalls implemented straightforwardly in similar way on both platforms
  - linux: uses ptrace to intercept entry/exit of every syscall and xfer control to monitor
    - monitor replaces syscall with effectless getpid
    - syscalls also used by pal to signal a xaxcall; monitor checks if shared memory contains legit xaxcall id/args
    - for alloc/free, replace syscall with mmap; this is because monitor can't alloc mem on behalf of child
    - 3 syscalls (slow); also if monitor crashes then child can make syscalls
      - fix by using kernel module
  - windows: custom kernel module xaxdrv
    - each windows thread has pointer to table of syscall handlers; xaxdrv replaces this
      - in replacement table, if caller is kernel mode, then pass through preserving dispatcher's stack frame; else, xaxcall
    - monitor can alloc/free on behalf of child
    - easy to port to many windows; just change some pointer values
    - could also have patched every entry in std syscall table, but discouraged since it affects every process i the system
  - loaders: have elf and pe-coff loaders
  - browser integration: local server appears as same origin; most URL requests go through to host but `/_xax/` refers to existing/new picoprocess
- examples
  - headline reader (audio) and 3D demo (10 fps) shows we can deliver rich content
  - social network visualizer shows utility of leveraging existing graphviz legacy code
  - ghostscript (pdf) and kaffe (jvm) shows this can replace browser plugins
- evaluation
  - performance: high xaxcall overhead; fast(er) as java; much faster than v8
  - legacy: apps use 15 libs totaling 3.3M loc in 4 langs with minimal changes
  - os-indep: linux & many windows
  - security: trusted code base (TCB) less tha jvm/flash
- related work
  - TODO
- limitations
  - threading: need a new xaxcall for spawing & asynchronous signaling
  - porting more mainstream C libs like glibc/MS is harder since they rely on
    x86 segment registers to manage thread-local storage, which can't be
    assigned in user mode, so must emulate or obviate this functionality
  - port more interactive code: GUI libs with few deps (qt/embeded); blit frame
    buffers; keyboard/mouse events catpure in js

umview

- linux sandboxing tool; uses ptrace
- tried contributing some kernel patches for ptrace perf (pmulti)

web
---

forcehttps

- stricter https error processing; treat errors not as possible misconfigs but
  as attacks
- prohibit mixed http/https
- simple url rewriting rules: //foo.com/blah gets the current http/https
  prepended

low-level
---------

MODERN EXPLOITATION AND MEMORY PROTECTION (alexander sotirov)

- memory corruption vulns: stack cookies/canaries, NX mem, ASLR
- windows mitigations: GS, SafeSEH, DEP, ASLR, SEHOP
- vuln classes: stack overflows, heap overflows, fmt strings, int overflows
- assumptions
  - fixed addrs of stack & exes
  - fn ptrs at well-known locs
  - heap allocator that trusts heap metadata
  - executable data on stack and heap
- mitigations
  - GS: stack cookies, var reordering, strict_gs_check
  - safeseh: handler chain, validation
  - heap protection: safe unlinking, safe lookaside lists, heap metadata cookies, heap metadata encryption
  - DEP: NX support, permanent DEP, optout mode by default
  - ASLR: PEB/TEB, heap, stack, images
- detect mem corruption: GS stack cookies, SEH chain validation (SEHOP), heap
  corruption detection
- stop common exploitation patterns: GS var reordering, safeseh, DEP, ASLR
  - rand cookie is generated every run; xor fn ptrs w rand cookie; code that
    uses the fn ptr xor's
- cookies
  - perf impact to cookies
  - ways to bypass; addressed by reordering; still a few special case vulns (eg
    overriding EHs, fmt strings)
- safeseh is a list of valid exception handlers which is checked before jumping
  to an exception handler
  - however, requires all DLLs to be compiled using SEH; single non-compat DLL
    is enough to bypass protection
  - control flow modification still possible
- SEH chain validation (SEH override protection aka SEHOP)
  - each stack frame is chained by a linked list
  - put random cookie at end of linked list
  - on exception, walk entire list and validate that the end of list has cookie
  - if SEH record is overwritten, SEH chain will break and cookie won't be found
  - no known bypasses
  - exception handling is already pretty slow by design
- DEP: off by default for compat reasons (eg JVM)
  - IE8 finally turned on DEP for plugins
  - return oriented shellcode (ret2libc): DEP w/o ASLR is completely useless