Bug 7620 - (int-131515) Browser process opens ports on all interfaces.
: Browser process opens ports on all interfaces.
Product: Browser
MicroB engine
: 5.0/(2.2009.51-1)
: N900 Maemo
: Unspecified normal with 2 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: microb-bugs
: security
  Show dependency tree
Reported: 2010-01-04 00:37 UTC by r.c.g
Modified: 2010-03-15 20:51 UTC (History)
4 users (show)

See Also:



You need to log in before you can comment on or make changes to this bug.

Description r.c.g (reporter) 2010-01-04 00:37:17 UTC
None - Problem exists in the factory default settings.

The browser process should not listen on external interfaces, or an option
should be provided to turn this behavior off.
Another alternative (if technically possible) would be to make the process only
listen on the local loopback interface.
This problem is discussed also in the following thread:

A "browser" process running as user opens by default a random unprivileged UDP
port on all network interfaces. After some browsing also open (listening) TCP
ports could be discovered also after the browser window (GUI) was closed.




User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:
Gecko/20091227 Gentoo Firefox/3.5.6
Comment 1 Lucas Maneos 2010-01-04 03:57:49 UTC
Confirmed also on 2.2009.51-1.  Seems like an oversight to me, at least I can't
think of a good reason why it can't only bind to the loopback interface.
Comment 2 timeless 2010-01-11 23:28:31 UTC
well. you can easily get udp *:1900 and udp *:39400 in browser ui by using
'open file' from the bookmarks view. Those are UPnP (which makes sense, it can
try to show you random shares -- i doubt they'll work, but hey!) and SIP (i
can't explain this one and don't want to, but it's clearly coming from the
dialog, so it isn't our fault).

So, here's the deal: i don't care what you think, but giving a bug without
steps to reproduce is not acceptable.

Steps to reproduce should not be "gleaned" by reading another web page after
having read your useless rant.

Here are the steps I used for testing:

1. open xterminal
2. while true; do lsof -u4|grep UDP; done
3. open browser (=bookmarks)
4. switch to xterminal, see nothing
5. switch to browser (bookmarks)
6. tap on facebook
7. switch to xterminal, see udp for DNS resolution by browserd
8. close browser
9. open another xterminal
10. killall browser
11. open browser (=bookmarks)
12. tap the title area
13. tap open file
14. switch to xterminal, see udp for 1900 (UPnP) and 39400 (SIP)
15. switch to browser (=file picker)
16. close the file picker
17. switch to first xterminal, press enter, see more for udp 1900/39400
18. switch to second xterminal
19. killall browser

Nothing interesting. But this is "steps to reproduce" and any bug without them
will be summarily marked as invalid.

Your steps don't have to be good, but they have to exist. At the very least you
need to include steps 1 and 2 in any bug you file.

This was with an internal build from this week. However my point stands. I do
not want to see a bug without steps to reproduce. Do not reopen this bug. Do
feel free to file a proper bug with steps to reproduce. Don't worry, your bug
will not be ignored if you file it properly.
Comment 3 timeless 2010-01-12 00:03:31 UTC
If someone wants to quibble about the resolution, it's probably "fixed in 53-2"
(it's what I had around, I'm not sure about 52). However I do not want to
reward poorly filed bugs with happy resolutions. And a bug filed on the 11th of
january without proper steps has nothing to do with a version that was already
working properly before that time.

wrt release plans, which we never discuss, my feeling is that there could be an
update that is roughly '51-1' as noted in comment 1, in which case that update
(after the 44-1) will not have it. There is always the chance of future minor
releases (44-1 was a minor release over 42-11), and as we are not sure what
'fixed' this 'bug', it is unlikely that whatever that was would end up in such
minor releases (even though it's likely that the numbers for that 'week' will
be 'newer' than the 53-2 mention above). Which means you're probably waiting
for the next 'major' release. And again, we never discuss release schedules.

I personally find out about release dates/numbers from customers when they tell
me they've installed their new shiny release (i.e. I get my news really late).
Comment 4 Andre Klapper maemo.org 2010-01-12 13:07:59 UTC
Seems to work fine in the internal version 2009.53-2, hence resetting to fixed.
Comment 5 Andre Klapper maemo.org 2010-01-12 14:00:43 UTC
*** Bug 7832 has been marked as a duplicate of this bug. ***
Comment 6 Andre Klapper maemo.org 2010-02-01 14:48:07 UTC
In internal version 2010.04-11:

# lsof -n|grep UDP|grep browserd 

=> verifying on behalf of reporter.
Comment 7 Andre Klapper maemo.org 2010-03-15 20:51:40 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).