SecurityTeam
Ubuntu Open Week - Ubuntu Security Team - Intro and Q+A - Kees Cook - Tue, Apr 29, 2008
[22:00] <jcastro> you're up kees!
[22:00] <kees> thanks jcastro :)
[22:00] <kees> Welcome everyone! This is going to be a quick intro to how the Security Team operates within Ubuntu
[22:01] <kees> the main entry-point for information about the team is here: https://wiki.ubuntu.com/SecurityTeam
[22:01] <kees> our wiki page is still a big young, so pardon the lack of details in the FAQ and KnowledgeBase areas.
[22:02] <kees> I'm hoping we might be able to populate some of the FAQ with today's intro's questions. :)
[22:02] <kees> The most active subteams within the Security Team is "ubuntu-security" and "motu-swat"
[22:03] <kees> when there are updates that need to happen, these two teams are the ones handling it usually.
[22:03] <kees> in general, our "update procedure" is here: https://wiki.ubuntu.com/SecurityUpdateProcedures
[22:03] <kees> we focus on fixing "CVE"s in published ubuntu releases
[22:04] <kees> a CVE is basically a number identifying a flaw in software that has security implications
[22:04] <kees> the central collection of CVEs here: http://cve.mitre.org/
[22:05] <kees> since CVEs are global identifiers, they cover software (and hardware) from any vendor in the world --
only some CVEs apply to Ubuntu software.
[22:05] <kees> (CVE stands for Common Vulnerabilities and Exposures)
[22:06] <kees> the first step to fixing security problems in Ubuntu is keeping up to date with new CVEs, and checking
to see in Ubuntu is affected.
[22:06] <kees> to help coordinate between teams and people, we have an ubuntu-specific reponsitory for tracking CVEs:
https://code.launchpad.net/~ubuntu-security/ubuntu-cve-tracker/master
[22:07] <kees> this is a bzr branch, with details about every CVE that has been issued (most are flagged "ignore"
since they apply to unpackaged software, different vendors like Apple or Microsoft, etc)
[22:07] <kees> 21:06 < firefly2442> QUESTION: On average, how long does it take from a vulnerability being discovered
to an updated DEB file being available? Does
[22:07] <kees> this change much if the issue is upstream?
[22:08] <kees> the speed of update depends greatly on the severity of the issue.
[22:08] <kees> once CVEs have been identified, the team will prioritize them, and start either tracking down patches
or making our own.
[22:09] <kees> some CVEs are private for a while while upstream (and the vendors) try to figure out solutions. This
is called an "embargoed" issue.
[22:09] <kees> the ubuntu tracker only shows public CVEs, since none of the vendors are allowed to discuss embargoed
issues until they reach their "coordinated release date"
[22:11] <kees> but, to answer firefly2442's question, I would say roughly under a few days for high-priority issues
(these issues tend to start embargoed, so there is plenty of time to fix them before they're public)
[22:11] <kees> under a month for medium issues, and "low" issues can be pretty different.
[22:12] <kees> some of the URLs for more information that I'm listing here can also be found in our KnowledgeBase:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase
[22:13] <kees> once the teams get issues fixed, then they test them, and finally publish the fixes.
[22:13] <kees> presently, security updates for main/restricted packages (mostly handled by "ubuntu-security") get
"Ubuntu Security Notices" (USNs) published
[22:14] <kees> http://www.ubuntu.com/usn/ there is a mailing list for this as well:
http://lists.ubuntu.com/archives/ubuntu-security-announce/
[22:15] <kees> besides the two teams handling security updates, we also have a team dedicated to providing better
security globally to Ubuntu. this is the "ubuntu-hardened" team. It started very SELinux-centric, but has grown to
include people interested in AppArmor and other hardening techniques
[22:16] <kees> we also have a "white hat" team ("ubuntu-whitehat") that is dedicated to hunting down new security
issues. it is young, but growing up nicely.
[22:16] <kees> since all of the teams are rather small, we still use a single IRC channel (#ubuntu-hardened) and a
single mailing list (ubuntu-hardened)
[22:17] <kees> 21:15 < pschulz01> QUESTION: What proportion of CVE's get fixed prior to the embargo date?
[22:17] <kees> I don't have specific numbers, but in general, if a CVE is embargoed, and high priority, it is fixed
before the embargo. The embargo dates are chosen to help all the vendors get their fixes ready.
[22:18] <kees> so, I would say it is close to 100%.
[22:18] <kees> 21:13 < ubuntu_demon> Question : Is Ubuntu using salted md5 passwords or something else ?
[22:19] <kees> yes, the current default for /etc/shadow is salted md5. (see "man shadow")
[22:19] <kees> Should sha-512 be used or something stronger ?
[22:19] <kees> I wouldn't be against it, but it would take a certain amount of coordination.
[22:20] <kees> salted md5 is still out of reach for even well organized collaborative cracking efforts.
[22:20] <kees> 21:13 < RzR> QUESTION: what kind of tools do you recommend to developpers to achieve better quality ? i
am think about valgrind etc
[22:20] <kees> valgrind is an excellent tool for locating memory corruption.
[22:21] <kees> for compiled programs, I tend to believe in: -Wall -Werror -Wformat -Wformat-security
-D_FORTIFY_SOURCE=2 -O2
[22:21] <kees> hm, and -Wl,-z,relro
[22:21] <kees> these kinds of hardening details can be found here: https://wiki.ubuntu.com/Security/HardeningWrapper
[22:22] <kees> beyond that, avoiding common pit-falls (named files in /tmp, etc) is a good idea. I will add a "best
practices" checklist to the KnowledgeBase
[22:23] <kees> 21:19 < ubuntu_demon> Question : Are you aware of https://help.ubuntu.com/community/UnsafeDefaults ?
Should any of these things be changed by
[22:23] <kees> default ?
[22:23] <kees> I wasn't personally aware of that page, but I was hoping to review a bunch of the defaults in Ubuntu
now that the LTS is out the door.
[22:24] <kees> can someone link to that page from the roadmap: https://wiki.ubuntu.com/SecurityTeam/Roadmap ?
[22:24] <kees> 21:20 < ubuntu_demon> Question : What kind of coordination would be needed to use SHA-512 ?
[22:25] <kees> I'm not 100% sure, but generally making sure there is clean backward compatibility when moving to it,
discussing it with upstream glibc, etc.
[22:25] <kees> 21:20 < ubuntu_demon> Question : What about cold boot attacks against Ubuntu's disk encryption ? Can
they be prevented somehow ?
[22:26] <kees> The cold-boot stuff is pretty extreme. Since there tend to be more pressing matters to investigate,
this hasn't really been addressed very much yet.
[22:26] <kees> 21:21 < ubuntu_demon> Question : What about memory protection ? Are ASLR and similar techniques
completely implemented or are there still some parts
[22:26] <kees> missing ?
[22:26] <kees> 8.04 has full memory protection available in the kernel (\o/).
[22:27] <kees> the "last piece" of ASLR is to get programs compiled to take advantage of the executable-image-ASLR
[22:27] <kees> stack and libs (and mmap) happen automatically.
[22:28] <kees> 8.10 will have heap (brk) ASLR separate from the exec ASLR, which will be nice too.
[22:28] <kees> 21:21 < ubuntu_demon> Question : What about wrapping web-browsers in apparmor ?
[22:28] <kees> I think this is a good idea, but it's not very trivial.
[22:29] <kees> I am (and the rest of the ubuntu-hardened team is) very interested in getting more AppArmor profiles (and SELinux policies) written to cover more of our common use-cases
[22:30] <kees> we've been slowly adding them, and there was a strong push to get "by-default" profiles active for a
number of common server services, done by the server team. We're hoping to help the desktop team do the same for
various network-facing tools like the browsers.
[22:31] <kees> 21:27 < toobuntu> QUESTION: SAK implementation currently closes everything that has /dev/console open,
including entire tty7 (X), while Windows has
[22:31] <kees> the option to require Ctrl-Alt-Del prior to entering a log on password. What would
be involved to implement something like this
[22:31] <kees> for Ubuntu?
[22:32] <kees> This is a good idea -- adding it to the Roadmap would be appreciated.
[22:33] <kees> SAK: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=Documentation/SAK.txt;hb=HEAD
[22:34] <kees> as a quick aside to the "best practices" question earlier, Debian and Ubuntu have been coordinating to
create a "hardening-wrapper" tool that is used as a Build-Dep for packages.
[22:34] <kees> (full disclosure: I wrote it)
[22:34] <kees> some details are here: http://wiki.debian.org/Hardening and
http://lists.debian.org/debian-devel-announce/2008/01/msg00006.html
[22:35] <kees> (both related to the earlier URL https://wiki.ubuntu.com/Security/HardeningWrapper)
[22:35] <kees> so that's the quick over-view -- I've clearly started answering questions already. :)
[22:35] <kees> for people interested in getting involved, please see
https://wiki.ubuntu.com/SecurityTeam/GettingInvolved
[22:36] <kees> that covers the various subteams, and what each does. We're low on people, so we'd love to have people
join to help get things fixed and help test. :)
[22:36] <kees> 21:36 < Azag> I am saying that, why a encrypted password can't be stolen
[22:37] <kees> presently, encrypted passwords are handled by specially-privileges processes. As such, regular users
do not have access to the process or the files they interact with
[22:38] <kees> for example /etc/shadow is not world-readable, and the various PAM helpers need to be run with elevated privileges to read it
[22:39] <kees> we've got a lot of time left, but I appear to be the last session for today. :)
[22:39] <kees> If anyone has other questions, please feel free to join #ubuntu-hardened or to ask on the
ubuntu-hardened mailing list.
[22:41] <kees> 21:40 < nealmcb> QUESTION: What good options are there (now or planned) for better authentication and
authorization in Ubuntu?
[22:41] <kees> 21:40 < nealmcb> (than passwords)
[22:42] <kees> there have been discussions about fingerprint readers, and other "something you have" style
authentications. at present, passwords seem to remain the standard
[22:42] <kees> 21:41 < Rudd-O> QUESTION: addressing rootkits and the like, what kinds of tools are there available to aid in detection and cleanup, and how are
[22:42] <kees> they being integrated into ubuntu?
[22:43] <kees> kernel-level things have been added in 8.04 to make rootkits harder to get installed (kernel memory
protections)
[22:44] <kees> as for detection and cleanup, most of the tools I know of are in the universe repository (chkrootkit,
rkhunter, unhide)
[22:44] <kees> luckily, rootkits are becoming more and more rare.
[22:49] <kees> 21:48 < ubuntu_demon> QUESTION : You are saying that md5 salted passwords are adequate for now but do
you think this will stay be the case for the next five years ? (because Hardy will be supported for five years)
[22:50] <kees> barring extreme breaks in the hashing function, md5 will probably be okay. it tends to be less of an
issue since only root has access to the file to begin with. leaving salted md5 in the clear certainly makes me
nervous.
[22:51] <kees> but, since we will likely have experience converting to the next cool hashing function, we'll be able
to apply that to LTS as well, if it's needed.
[22:53] <kees> any missed questions?
[22:54] <kees> 21:53 < ZehRique> QUESTION: Concerning the nealmcb question, what about creating an authentication
process like Brazilian banks, where the password is typed with mouse clicks on a java applet which shows the numbers
and letters randomly positioned on the screen, to difficult some kind of password steal?
[22:54] <kees> there is no reason it can't be done for the gdm/kdm login screen -- it just requires someone to write
it. :)
[22:55] <kees> okay, thanks for listening to the session! feel free to catch me on IRC if you think of anything else
to ask. :) thanks!
[22:55] <jcastro> ok
[22:55] <jcastro> thanks everyone for coming!
[22:55] <jcastro> The sessions begin again at 1500UTC tomorrowMeetingLogs/openweekhardy/SecurityTeam (last edited 2008-08-06 16:27:41 by localhost)