Hi list, for the archive; from the OpenOffice.org mailing list. http://distribution.openoffice.org/servlets/ReadMsg?list=mirrors&msgNo=1049 ) The issues raised in this mail apply to other projects as well. This is the vision that I would like to elaborate on. Maybe it can become a shared vision. Peter Anfang der weitergeleiteten E-Mail: > Von: Peter Pöml <poeml_at_cmdline.net> > Datum: 4. Dezember 2009 12:26:47 MEZ > An: mirrors_at_distribution.openoffice.org > Kopie: Anthony Bryan <anthonybryan_at_gmail.com>, "Neil M." <nabber00_at_gmail.com > >, Hampus Wessman <hampus.wessman_at_gmail.com>, hayden_at_halogenware.com > Betreff: Re: [mirrors] tamper-proof mirror network > Antwort an: mirrors_at_distribution.openoffice.org > > Hi Tora, > > thanks for bringing this up! > > Warning: long mail. > > Am 03.12.2009 um 08:01 schrieb tora - Takamichi Akiyama: >> To prevent attackers from tampering files in the mirror network, >> what can we do? > > I have a clear vision: > > Sign content, provide these signatures from a trusted source, and > enable users to use them as easily as possible. > > Signing content and providing the signatures securely is > straightforward. > > The third step, enabling users to easily make use of them, is not so > straightforward. Educating users to perform manual steps works only > so far. So, making it as easy as possible is the way to go. > > An important part is updating. A major portion of downloads are > updates. When the initial OpenOffice.org install was obtained in > intact form, it can be the vehicle for all later downloads. In fact, > the program already does that - it downloads updates and extensions. > In this situation, it would be easy to automate the required > verification procedure for downloading, on behalf at the user, and > don't bother them. This would be pretty straightforward: the > required server-side technology not only exists, but is already in > place[1]; the required client-side support can be implemented pretty > easily by using an existing Metalink client, or re-using existing > code. Thus, it seems very feasible to implement automatic > verification for updates, by making use of the provided metadata. > > [1] the new redirector at http://download.services.openoffice.org/ > provides reliable download descriptions, including MD5, SHA-1 and > SHA-256 hashes, for all files. (It would also provide PGP signatures > if they existed.) These download descriptions (Metalinks) are > provided only by the origin server, and not through the mirror > system - which mainly leaves vulnerabilities through man-in-the- > middle attacks, and even those could be avoided by adding an HTTPS > virtual host to the server. > > > So much concerning updating. For initial downloads (or, more > generally, downloads initiated by using a web browser, going to > download.openoffice.org etc.), the situation is different. > Unfortunately, the means that web browsers provide to detect > tampering are minimal^Wzero. This is a shortcoming that needs to be > fixed over time separately. See also Anthony's post. OpenOffice.org > is, of course, not the only content provider who cares about the > security of their users (and their good name). Others are working on > this as well. IMO, it is very good to join forces on this difficult > subject. The mailing list discuss_at_mirrorbrain.org is open for this > purpose, and I would like to invite everyone to take the discussion > of this subject onto a higher level - above the level of individual > projects. > > One idea would be to provide a download client via an applet in the > web browser. It is feasible with today's technology to launch a > Metalink client from a web browser. It requires a digital > certificate for signing the applet/application. And depending on > browser security settings a warning dialog may still pop up. > However, this does work; Hayden Legendre from Halogenware (author of > Retreiver, a download program) has created a proof-of-concept applet > of his Retreiver using applet and JNLP technology. I proposed this > as GSoC project in 2009 but didn't find the time to search a > student... > > Well, guess what the big guys do? (Akamai, the largest operator of a > Content Delivery Network.) They have made "Download Manager". Read > about it here: > http://www.akamai.com/html/technology/products/http_downloads.html > http://www.akamai.com/dl/feature_sheets/Akamai_Download_Manager_FS.pdf > I quote: "When a user requests a large file download, Download > Manager is automatically sent to their computers. It launches > immediately, asking the user where the file should be saved." Sounds > familiar? You've heard that before? Yes, they do the same that we > _want_ to do. And believe me, Akamai know their business ;-) > > > A variant of this idea, which might be simpler, would be to provide > a downloadable small binary, and the user is asked to execute it > after downloading it (which is a procedure that most people are used > to). This binary could be a minimal Metalink client that implements > the essential features (downloading, verification, and spiced with a > little bit of failover). This client would be specialized to > download OpenOffice.org, and could start with a little chooser that > offers the current OOo variants to choose from, plus optional > downloads. Of course it would need to be nice and real easy and user- > friendly. But it would do nothing else. > > Since the client would be small, it could be served from trusted > servers via HTTPS, and since it would verify all further downloaded > content, we would be _fully_ covered. > > Mini Downloader (see http://groups.google.com/group/metalink-discussion/browse_thread/thread/a6e4d2a6863b061f > ) pushes into a similar direction and might be worth a look at. > And there is AppUpdater (see http://www.nabber.org/projects/appupdater/ > and paper presented at http://www.cs.cmu.edu/~tdumitra/hotswup09/papers/hotswup09_submission_3.pdf > -- http://www.hotswup.org/2009/ -- "Hot Topics in Software Upgrades > '09" - what the odds :-)). > > Furthermore, we would be free to use such a downloader as an > instrument for feedback at the same time: if anything bad happens, > it can submit the log upstreams. Just like a crash reporter that > sends backtraces to a server collecting them. This would give us > several levers that are important for controlling quality of the > distribution: > - identifying network problems and bottlenecks > - identifying servers delivering broken content (forged or not) > - optimizing mirror selection > - statistics > > And, the best of all, the downloader wouldn't need to be OOo-only. > It could be fully reusable -- and would be picked up by other > projects, I'm sure. > > It just needs to be small, and platform-independent, user-friendly. > > A download applet (in the browser) would also be a good candidate > for reuse by others. > > >> In other words, how can we make the OpenOffice.org mirror network >> unattractive for attackers? > > With the above proposal, it would actually become a _challenge_ ;-) > > Joking aside: currently, I'd find it very attractive: I saw _very_ > few signatures in the file tree. > I know that MD5 sums are published somewhere on the web, but afaik > they are not immediately visible to the downloading user, and > furthermore it'd be a manual process to check them. > > The http://download.openoffice.org/contribute.html page that the > user is redirected to, after clicking on the download, doesn't even > mention the possibility of verifying the download, as far as I can > see. It should! > > Although the new redirector can provide hashes for all files on its > own, it would be valuable if the most important ones would already > exist in the filesystem: by publishing them together with the files > themselves. Adding a .md5 and .sha1 file could go hand in hand with > PGP-signing the files (which can only happen in the build system > anyway, and not on the download server). > > I do find a few MD5 hashes, but they are not available consistently > - I see extended/3.1.1rc2/3.1.1rc2_md5sums.txt and extended/ > developer/OOO320_m6/OOO320_m6_md5sums.txt. The former seems outdated > (because it is about a release candidate), while the latter is very > recent. Both are 90 kilobyte files though, which neither practical > to download, nor easily visible in the file system. Having the > checksums combined in a large liste makes the list less suited to > distribute via HTTPS, and less easy to use (or even download) in an > automated way. The common convention to use foobar.md5, foobar.sha1 > and foobar.asc would be _very_ good to follow here. > >> (a) Geographically adaptable bouncer might help organized attackers. > > Nah, not really, if you meant redirection by client location. Do > you? It shouldn't matter if a mirror network is "geographically > adaptive" (uses network locality) to distribute traffic. It just > means that other users are affected. Exploiting network locality > limits the effect of a compromised mirror server to a certain region > (a geographical limitation only of course). > >> Assume that an attacker targets at country X. They would deploy >> a mirror server in the country and ask us to register it as one >> of the mirror servers. It would be acting as a normal mirror at >> ordinary times. As a new version of OpenOffice.org is released, >> it will start to deliver tampered software instead of genuine one. >> >> Download requests from users in the country would be transfered >> to one of the registered mirror servers within the country. >> Consequently, the users in the targeted country would have tampered >> ones in the high rate of possibility. Meanwhile, users in other >> countries would not be affected. >> >> >> (b) How to identify an owner and location of the mirror server. >> >> If something wrong happens, we might be involved in the incident >> and might be required to help authorities in the country. >> >> An IP address of the server would identify its Internet service >> provider. The ISP should know about the subscriber and location, >> but the ISP, in general, would not disclose such information. >> >> A domain name of the server would identify its registrant through >> WHOIS service. Registrant is obligated to enter correct, >> up-to-date information on the registrant in the WHOIS database, >> but in reality, some leave obsolete information, some intentionally >> enter inaccurate information to protect their privacy, some hide >> their information behind secret service, etc. >> >> In contrast, domain name registrar should know about the registrant >> such as name, credit card information, billing address, but the >> registrar, in general, would not disclose such information. >> >> >> (c) How to quickly detect tampered files. >> >> Our primary users are casual users. They do not care about MD5 >> checksum. >> >> Digital signature has not yet implemented in OpenOffice.org >> installer. >> Even though it is implemented, it might not help because users would >> just click on a button Next whatever the installer warns. Moreover, > > "You have been warned." > >> OpenOffice.org can be built by anyone. That implies that anybody >> should be able to do the digital signature if it is implemented. > > Well. While anyone can build OpenOffice.org, not anyone can access > the download infrastructure and distribute builds through the > trusted network. I don't thing that anyone should be able to use it. > Neither that anyone should be able to sign the builds (with the same > keys). On the contrary, we leave this to a comparably small group > that we lend our trust. That's okay, isn't it? > > >> >> The longer duration leaving the tampered files available in the >> malicious mirror server, the more victims. >> >> Therefore, quickly detecting tampered files and immediately stopping >> all bouncers or eliminating the questioned server entries from >> all bouncers might be crucial under the current circumstances. >> But how? > > As a start, it would be very useful to start spreading digital > signatures for all releases. There are always some people who _do_ > check them. It's only a small percentage of the mass of downloading > people, but nonetheless those are the people who initially find out > about possible problems -- some of them will track them down and > notify us. At least these people need to be enabled to easily check > signatures. This encompasses providing > - .md5 file with the MD5 sum (which is the hash which is verifiable > on most platforms), > - .sha file with the SHA-1 sum (which is better, but not available > everywhere), and a > - .asc file with the detached PGP signature (which is most secure, > but the least people are able to use it) > > A good example is http://www.apache.org/dist/httpd/ > I also like that instructions and keys are available as well: http://www.apache.org/dist/httpd/KEYS > > (Note that the detached hash and signature files are not be > redirected to mirrors.) > > > Now, while this can work as an alarm system, it is only a start and > better than nothing; in the end, verification of downloads must > happen on all end-user systems. See above :-) > > > >> ===== >> I believe 99.999% of the mirror servers currently registered in our >> mirror network are trusted. However, we would need to consider >> potential vulnerability of our system and process and to prepare >> for possible attacks. > > Indeed, the trustfulness that we built up (developers, mirror > operators, users) is what connects us all and what keeps the whole > thing together. Which is nothing but wonderful. This can't stay > unsaid in a discussion like this. > > I definitely share this feeling of trust [*], but: > > It doesn't matter how trustful everybody may be -- because it is > trivial to launch a man-in-the-middle attack by IP address spoofing, > DNS cache poisening and similar techniques. Yes, it _is_ indeed > trivial. > > Such attacks can't be prevented, but their purpose defeated by > content verification. > > And it should be kept in mind, that in security there are no 100%. > However, the current situation leaves some things to desire. With > all the above, we'll achieve a _good_ level of security. > > Thanks for reading! > Peter > > > [*] Although I have been "part" of an experiment of undermining a > major mirror network in the past. And I can only second Anthony's > suggestion to read http://www.cs.arizona.edu/stork/packagemanagersecurity/ > [**], which is a highly informative reading. It may initially > appear to focus on Linux-specific issues; however, that's only > because those already go quite far regarding security, and the work > really explores the remaining corner issues. But it also covers the > basics. > > [**] also published later in a USENIX magazine, in a very readable > form - at http://www.usenix.org/publications/login/2009-02/openpdfs/samuel.pdf _______________________________________________ discuss mailing list Archive: http://mirrorbrain.org/archive/discuss/ Note: To remove yourself from this mailing list, send a mail with the content unsubscribe to the address discuss-request_at_mirrorbrain.org
This archive was generated by hypermail 2.2.0 : Fri Dec 11 2009 - 22:12:59 GMT