- Dillo-dev - lists.mailman3.com

[Dillo-dev]Re: Dillo potential DOS via redirect loop
by Jorge Arellano Cid Oct. 19, 2004

Oct. 19, 2004

Hi Kelson, On Mon, Oct 18, 2004 at 04:39:34PM -0700, Kelson Vibber wrote: > I was attempting to pull up the bug database for Wordpress > <http://mosquito.wordpress.org/> in Dillo 0.8.3rc2, and noticed that the > browser froze when I clicked on the "View bugs" link. After I killed it > and re-launched it from a command line, I saw it spewing Nav_open_url > messages over and over, alternating between these two lines: > > Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_bug_page.php< > Nav_open_url: Url=>http://mosquito.wordpress.org/view_all_set.php?type=0< Yes, it happens... > > I'm not entirely sure what the site is trying to do, but Firefox, Opera > and IE all seem to make it through okay. I suspect it's something like > this: > > 1. view_all_bug_page.php checks for a cookie. It doesn't find it, so it > redirects (302) to view_all_set.php?type=0 > 2. view_all_set.php sets the cookie, then sends the browser back to the > original page. > 3. Either Dillo hasn't accepted the cookie and view_all_bug_page.php > sends the redirect again, or Dillo has already cached the 302 response > and jumps to view_all_set.php anyway. > > Adding mosquito.wordpress.org to cookiesrc doesn't make a difference. Currently Dillo's cache is handling HTTP 30x answers as cacheable redirections. This is more a lack of implementation than a BUG (there's no code to handle 302 answers now). > > Based on the libwww-perl HEAD utility (which breaks out of the loop > after 7 redirects) and just telnetting to port 80, I've found the following: > > - They're using a 302 (temporary) redirect on both scripts > - They're setting a cookie on view_all_set.php. > - They're using relative URLs in the Location header (which I think is > technically not allowed, but has been used in practice for years.) Dillo handles relative locations. > Regardless of whether this setup is valid, it *does* make Dillo stop > responding. There is at least one bug here -- Dillo isn't detecting the > redirect loop and breaking out of it -- and possibly two (if it's > caching the 302/temporary status). Yes, there're two problems. Dillo hogging the CPU is a BUG that'd be better fixed for 0.8.3. The caching problem is a large issue that needs much more time to tackle. The cache problem is very interesting: if a browser happens to follow the SPEC, it becomes easy to abuse (e.g. pragma: no-cache advertising). OTOH, some sites can require to refresh some page contents in order to keep some meaningful state (HTTPS services usually use cache directives). Maybe as it happens with cookies, just allowing certain cites and honoring HTTP cache directives from that set only, is a good solution in the long term. I'll try to find a way to catch the redirection loop hog... -- Cheers Jorge.-

1 0

[Dillo-dev]Re: anchor names
by Matthias Franz Oct. 19, 2004

Oct. 19, 2004

Dear Sebastian, thanks for the quick bugfix. On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > The changes also make the viewport check, whether anchor names are > unique. If not, g_return_if_fail is called, which messages should not > be printed normally (and "normally" includes faulty web pages), > instead, normal HTML error messages should be shown. Probably, the > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > which returns, whether an anchor is already defined. If it returns > TRUE, an appropriate message is shown, and the anchor is not added. Why don't you let a_Dw_gtk_viewport_add_anchor return a result: FALSE = ok, TRUE = anchor already defined and not changed Then a_Dw_page_add_anchor could pass this on to html.c, where my patch would produce the HTML warning. Otherwise one would look up the hash table twice, once in a_Dw_gtk_viewport_check_anchor and once in a_Dw_gtk_viewport_add_anchor. All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

2 1

Re: [Dillo-dev]Re: race condition patch]
by Jorge Arellano Cid Oct. 18, 2004

Oct. 18, 2004

-- Cheers Jorge.-

1 0

[Dillo-dev]Re: anchor names
by Jorge Arellano Cid Oct. 18, 2004

Oct. 18, 2004

Hi there, This is half an email forward and half an answer. On Sun, Oct 17, 2004 at 04:32:09PM +0200, Sebastian Geerken wrote: > Hi, > > the dillo-dev mailing list does not seem to work, I always get an 550 > error, so I forward you the mail, which I did not succeed to send to > the list. > > Sebastian Now, 18 Oct, it works for me. I'm answering to dillo-dev because my test mail succeeded. > Date: Sun, 17 Oct 2004 15:54:40 +0200 > From: Sebastian Geerken <sgeerken(a)dillo.org> > Subject: Re: [Dillo-dev]anchors_table not cleared > To: dillo-dev(a)auriga.wearlab.de > Mail-Followup-To: Sebastian Geerken <sgeerken(a)dillo.org>, > dillo-dev(a)auriga.wearlab.de > > On Fri, Oct 15, Matthias Franz wrote: > > I'm writing a patch for a better treatment of anchor names in HTML pages. > > During this, I've come across the following bug in Dillo. > > > > Jorge: I think this is what produced the bug in the patch I sent you. > > > > Entries are never removed from the hash table anchors_table, which stores > > the anchors of a page (see dw_gtk_viewport.c). This means that whenever a > > new page is displayed in the same viewport, the old anchors remain in > > the hash table, but their keys are overwritten. Like in this example: > > (The "###" lines are debug information I've inserted.) > > > > [...] > > > > Obviously, the anchors_table must be cleared whenever a new page is > > displayed. I don't know the dw* part of Dillo very well, and the > > connection between the html structure and the viewport seems to be quite > > indirect. Can anyone suggest a fix? > > The latest commitment in CVS fixes this, the patch is also > attached. Jorge, I'm not sure, whether this should be included into > the release, since the changes are rather big, and currently, it only > fixes a memory leak. I'd prefer to leave it out of rc2. It's been more than four months since our last release. The one following 0.8.3 is going to have the new abstraction layer for Dw, and other changes, so just in case it takes some time to stabilize it, it'd be very good to have a solid 0.8.3 out there. I'll prepare the dillo-0.8.3-rc2 tarball ASAP and write back when it's ready for download... > > The changes also make the viewport check, whether anchor names are > unique. If not, g_return_if_fail is called, which messages should not > be printed normally (and "normally" includes faulty web pages), > instead, normal HTML error messages should be shown. Probably, the > best solution is to add a function a_Dw_gtk_viewport_check_anchor(), > which returns, whether an anchor is already defined. If it returns > TRUE, an appropriate message is shown, and the anchor is not added. Agreed. -- Cheers Jorge.-

1 0

[Dillo-dev]Is dillo-dev back? (test mail)
by Jorge Arellano Cid Oct. 18, 2004

Oct. 18, 2004

Hi, If this is readable, dillo-dev is up! -- Cheers Jorge.-

1 0

[Dillo-dev]anchors_table not cleared
by Matthias Franz Oct. 15, 2004

Oct. 15, 2004

Hi everybody, I'm writing a patch for a better treatment of anchor names in HTML pages. During this, I've come across the following bug in Dillo. Jorge: I think this is what produced the bug in the patch I sent you. Entries are never removed from the hash table anchors_table, which stores the anchors of a page (see dw_gtk_viewport.c). This means that whenever a new page is displayed in the same viewport, the old anchors remain in the hash table, but their keys are overwritten. Like in this example: (The "###" lines are debug information I've inserted.) ~$ dillo http://www.google.de dillo_dns_init: Here we go! Disabling cookies. ### Dw_gtk_viewport_init: anchors_table init Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://www.google.de< Dns_server [0]: www.google.de is 0x8100ea8 Connecting to 66.102.9.99 ### size(anchors_table) = 0 ### entries: ### Html_add_anchor: adding anchor 1a ### size(anchors_table) = 1 ### entries: <1a> ### Html_add_anchor: adding anchor 2a ### size(anchors_table) = 2 ### entries: <2a> <1a> ### Html_add_anchor: adding anchor 3a ### size(anchors_table) = 3 ### entries: <3a> <2a> <1a> ### Html_add_anchor: adding anchor 4a ### size(anchors_table) = 4 ### entries: <4a> <3a> <2a> <1a> ### Html_add_anchor: adding anchor all ### size(anchors_table) = 5 ### entries: <4a> <all> <3a> <2a> <1a> ### Html_add_anchor: adding anchor lgr ### size(anchors_table) = 6 ### entries: <4a> <all> <3a> <2a> <1a> <lgr> ### Html_add_anchor: adding anchor cty Nav_open_url: Url=>http://www.google.de/imghp?hl=de&tab=wi&ie=UTF-8< Connecting to 66.102.9.99 ### size(anchors_table) = 7 ### entries: <> <> <h3> <> <¸1> <À(> <> ### Html_add_anchor: adding anchor 0a ### size(anchors_table) = 8 ### entries: <0a> <> <> <h3> <> <¸1> <> <> ### Html_add_anchor: adding anchor 2a ### size(anchors_table) = 9 ### entries: <0a> <> <> <h3> <> <2a> <¸1> <> <> ### Html_add_anchor: adding anchor 3a ### size(anchors_table) = 10 ### entries: <0a> <> <> <h3> <3a> <> <2a> <¸1> <> <> ### Html_add_anchor: adding anchor 4a Dillo: normal exit! Obviously, the anchors_table must be cleared whenever a new page is displayed. I don't know the dw* part of Dillo very well, and the connection between the html structure and the viewport seems to be quite indirect. Can anyone suggest a fix? Thanks in advance, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

2 2

[Dillo-dev][marianne@mathematicians.de: Compatibility]
by Jorge Arellano Cid Oct. 15, 2004

Oct. 15, 2004

-- Cheers Jorge.-

1 0

[Dillo-dev]testing dillo-0.8.3-rc1
by Bjoern Brill Oct. 15, 2004

Oct. 15, 2004

Hello, I've tried out dillo-0.8.3-rc1 for a few days on a Debian GNU/Linux 3.0 "woody"/i386 system. It compiled and installed cleanly, and I did not encounter any regressions against 0.8.2 yet. The parser changes are a real improvement -- several formerly problematic sites I've tried work now, and the "Detected HTML errors" view produces much more meaningful results. Two small problems I've encountered: - It seems that, if a pair of <a href="..."> </a> tags contains something illegal, like <div>, then the <a> tags are ignored, rather than the illegal stuff inside. That's suboptimal. As an example, look at http://www.kmelektronik.de/ (admittedly a very broken site, standards-wise). The text fragments "Light-Version Versand" and "Light-Version Shop" near the page bottom should really be links. If this is hard to fix, then don't bother. - This one is not new, but I fixed it a while ago for myself and then forgot about it: the "This page uses the NON-STANDARD meta refresh tag..." warning usually occurs inside <head>, but is immediately sent to the parser, which in turn switches its HTML processing state from IN_HEAD to IN_BODY prematurely. After that, head-only tags like <title> and <base> are ignored. A minimal fix is at the end of the mail. Best regards, Björn Brill -- Bj"orn Brill <brill(a)fs.math.uni-frankfurt.de> Frankfurt am Main, Germany --- dillo-0.8.3-rc1/src/html.c.orig Tue Sep 21 17:42:12 2004 +++ dillo-0.8.3-rc1/src/html.c Tue Oct 5 19:21:42 2004 @@ -3101,7 +3101,11 @@ static void Html_tag_open_meta(DilloHtml /* Send a custom HTML message */ html_msg = g_strdup_printf(meta_template, content, delay_str); - Html_write_raw(html, html_msg, strlen(html_msg), 0); + { + DilloHtmlProcessingState SaveFlags = html->InFlags; + Html_write_raw(html, html_msg, strlen(html_msg), 0); + html->InFlags = SaveFlags; + } g_free(html_msg); } }

2 4

[Dillo-dev]Crash on fast reload for dpi pending...
by Jorge Arellano Cid Oct. 14, 2004

Oct. 14, 2004

Hi there, Please note that hitting reload as a mad man over a dpi-handled URL can crash Dillo. This happens because currently there's no code to account for this case (as there is for the HTTP branch). Thinking about it, there's a possibility of merging the CCC branches into a couple of generic and very powerful ones (much like what the dpi is now). If this design is possible, and succeeds, it would mean much simpler handling of IO, the elimination of a lot of complexity, more stability (all the data would use it and thus be more tested). I'll give it some thought. Not for the next release though... :-) -- Cheers Jorge.-

1 0

[Dillo-dev]dillo-0.8.3-rc1.tar.bz2
by Jorge Arellano Cid Oct. 14, 2004

Oct. 14, 2004

Hi there, The release of dillo-0.8.3 is very close now. Today I prepared the release candidate tarball for it. Please test and send some feedback; the last request for feedback on the CVS had a single answer. !? Get rc1 from: http://www.dillo.org/download/dillo-0.8.3-rc1.tar.bz2 It should be out in early September. -- Cheers Jorge.-

4 10