linux-igd-devel Mailing List for Linux UPnP Internet Gateway Device (Page 2)
Status: Beta
Brought to you by:
krazydime
Menu
▾
▴
linux-igd-devel — List for the Linux UPnP Internet Gateway Device developers
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(5) |
Aug
(21) |
Sep
(5) |
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
(7) |
May
(1) |
Jun
(7) |
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2008 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Nektarios K. P. <npa...@in...> - 2006-09-11 12:40:42
|
Daniel J Blueman wrote: > On 10/09/06, Nektarios K. Papadopoulos <npa...@in...> = wrote: >> I didn't look very thoroughly through the code, but see my comments >> inline... >> >> Juho V=E4h=E4-Herttua wrote: >>> I read through this and from what I can see it has at least four >>> patches combined together. >>> >>> First of all it disables the iptables command parsing totally in non- >>> linux systems. Another thing is that it adds checks for >>> UPNP_HAVE_DEBUG and moves some of the code inside that, apparently >>> libupnp log level and other logging stuff. (don't know the reason for >>> this, maybe linux-igd doesn't work on libupnp compiled without >>> debug?) >> AFAIK linux-igd is working fine with libupnp compiled without debug. >> AFAICT the purpose of the patch is just to make linux-igd take >> advantage/configure the debugging functionalities of the libupnp if >> available. >> >>> Third thing is that it refactors some linux-igd code (mainly >>> socket code) to linux.c file and adds netbsd.c file that does the >>> same with some modifications. And last but not least it adds the >>> ioctl stuff that is used to control netbsd filters. >>> >>> Then there's the libupnp patch he clearly couldn't get upstream at >>> libupnp so he sent it to us, it's a big piece in itself and seems to >>> concentrate in replacing some functions not found on netbsd. >> libupnp development is continued at the pupnp project: >> http://sourceforge.net/projects/pupnp >> http://www.libupnp.org >> I'm working on that project but I have zero experience with netbsd. >> pupnp is really positive about supporting new platforms but we're real= ly >> short on resources. BTW, is it ok if I post the patch there? >=20 > There should be a NetBSD vmware image which can be downloaded and used > with the free vmware player [http://www.vmware.com/download/player/]. > I checked, but couldn't find any so far. Thanks for the link. I couldn't find a NetBSD vmware image either.=20 Nevertheless, it will require more than having a usable NetBSD=20 installation to check/fix/verify such a patch. --=20 ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ |
|
From: Daniel J B. <dan...@gm...> - 2006-09-11 09:23:06
|
On 10/09/06, Nektarios K. Papadopoulos <npa...@in...> wrot= e: > I didn't look very thoroughly through the code, but see my comments > inline... > > Juho V=E4h=E4-Herttua wrote: > > I read through this and from what I can see it has at least four > > patches combined together. > > > > First of all it disables the iptables command parsing totally in non- > > linux systems. Another thing is that it adds checks for > > UPNP_HAVE_DEBUG and moves some of the code inside that, apparently > > libupnp log level and other logging stuff. (don't know the reason for > > this, maybe linux-igd doesn't work on libupnp compiled without > > debug?) > AFAIK linux-igd is working fine with libupnp compiled without debug. > AFAICT the purpose of the patch is just to make linux-igd take > advantage/configure the debugging functionalities of the libupnp if > available. > > > Third thing is that it refactors some linux-igd code (mainly > > socket code) to linux.c file and adds netbsd.c file that does the > > same with some modifications. And last but not least it adds the > > ioctl stuff that is used to control netbsd filters. > > > > Then there's the libupnp patch he clearly couldn't get upstream at > > libupnp so he sent it to us, it's a big piece in itself and seems to > > concentrate in replacing some functions not found on netbsd. > libupnp development is continued at the pupnp project: > http://sourceforge.net/projects/pupnp > http://www.libupnp.org > I'm working on that project but I have zero experience with netbsd. > pupnp is really positive about supporting new platforms but we're really > short on resources. BTW, is it ok if I post the patch there? There should be a NetBSD vmware image which can be downloaded and used with the free vmware player [http://www.vmware.com/download/player/]. I checked, but couldn't find any so far. --=20 Daniel J Blueman |
|
From: Nektarios K. P. <npa...@in...> - 2006-09-10 16:12:04
|
I didn't look very thoroughly through the code, but see my comments=20 inline... Juho V=E4h=E4-Herttua wrote: > I read through this and from what I can see it has at least four =20 > patches combined together. >=20 > First of all it disables the iptables command parsing totally in non-=20 > linux systems. Another thing is that it adds checks for =20 > UPNP_HAVE_DEBUG and moves some of the code inside that, apparently =20 > libupnp log level and other logging stuff. (don't know the reason for =20 > this, maybe linux-igd doesn't work on libupnp compiled without =20 > debug?) AFAIK linux-igd is working fine with libupnp compiled without debug.=20 AFAICT the purpose of the patch is just to make linux-igd take=20 advantage/configure the debugging functionalities of the libupnp if=20 available. > Third thing is that it refactors some linux-igd code (mainly =20 > socket code) to linux.c file and adds netbsd.c file that does the =20 > same with some modifications. And last but not least it adds the =20 > ioctl stuff that is used to control netbsd filters. >=20 > Then there's the libupnp patch he clearly couldn't get upstream at =20 > libupnp so he sent it to us, it's a big piece in itself and seems to =20 > concentrate in replacing some functions not found on netbsd. libupnp development is continued at the pupnp project: http://sourceforge.net/projects/pupnp http://www.libupnp.org I'm working on that project but I have zero experience with netbsd.=20 pupnp is really positive about supporting new platforms but we're really=20 short on resources. BTW, is it ok if I post the patch there? >=20 > Personally I think this patch should be divided into smaller pieces =20 > and I'm not even sure all of it should be applied. The #define =20 > __linux__ for one is very ugly, it would be much better practice to =20 > add new defines for the problematic pieces or rewrite them to work on =20 > all systems, it is possible. But who knows japanese enough to reply =20 > to this guy? He clearly can't speak english... :p Perhaps we can use machine translation too :p >=20 >=20 >=20 > Juho >=20 >=20 > On 7.9.2006, at 18:36, ew...@er... wrote: >> -----Original Message----- >> From: Kouji Suzuki [mailto:k...@ke...] >> Sent: Thursday, September 07, 2006 11:00 AM >> To: di...@gu... >> Cc: ew...@er... >> Subject: Linux IGD was ported to NetBSD. >> >> Dear Mr. Glover. >> >> # Because the machine translation is used, # the sentence might be not >> correct. >> >> I succeeded in the movement of LinuxIGD-0.95 on NetBSD-3.0. >> Please merge this patch with LinuxIGD. >> >> In NetBSD, NAT is controlled by using PF. >> PF uses the pfctl command usually. >> However, this patch is controlled directly by using ioctl. >> Perhaps, it corresponds to iptc in linux. >> >> The thing of the separation of the fire wall function was being =20 >> written on >> the ToDo page. >> This patch considers the thing a little. >> >> The code shown in linux was described in linux.[ch], the code shown in >> NetBSD was described in netbsd.[ch], and the code shown in PF made it >> describe in pf.[ch]. >> However, it is still imperfect. >> >> To ensure it, it thinks the code that uses the iptables command to =20 >> be should >> separate. >> However, it decided to avoid it in the fear of the patch's growing. >> >> Moreover, because the development of libupnp-1.3.1 stops, the patch =20 >> to the >> library is put in ./etc. >> This patch assumes the person who thinks that it uses it with =20 >> NetBSD applies >> by himself/herself. >> Therefore, please append it as it is. >> >> >> Best regards. >> >> ---------------------- >> Kouji Suzuki >> mailto:k...@ke... >> # It will be automatically discarded if the attached file of # =20 >> executable >> files or "HTML mail" is transmitted to this mail address. >> <linuxigd-0.95-nb.diff.bz2> >> ----------------------------------------------------------------------= =20 >> --- >> Using Tomcat but need to do more? Need to support web services, =20 >> security? >> Get stuff done quickly with pre-integrated technology to make your =20 >> job easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache =20 >> Geronimo >> http://sel.as-us.falkag.net/sel?=20 >> cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D121642______________________= ________=20 >> _________________ >> Linux-igd-devel mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-igd-devel >=20 >=20 > -----------------------------------------------------------------------= -- > Using Tomcat but need to do more? Need to support web services, securit= y? > Get stuff done quickly with pre-integrated technology to make your job = easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron= imo > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 > _______________________________________________ > Linux-igd-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-igd-devel >=20 --=20 ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ |
|
From: <juh...@tk...> - 2006-09-07 16:19:26
|
I read through this and from what I can see it has at least four patches combined together. First of all it disables the iptables command parsing totally in non- linux systems. Another thing is that it adds checks for UPNP_HAVE_DEBUG and moves some of the code inside that, apparently libupnp log level and other logging stuff. (don't know the reason for this, maybe linux-igd doesn't work on libupnp compiled without debug?) Third thing is that it refactors some linux-igd code (mainly socket code) to linux.c file and adds netbsd.c file that does the same with some modifications. And last but not least it adds the ioctl stuff that is used to control netbsd filters. Then there's the libupnp patch he clearly couldn't get upstream at libupnp so he sent it to us, it's a big piece in itself and seems to concentrate in replacing some functions not found on netbsd. Personally I think this patch should be divided into smaller pieces and I'm not even sure all of it should be applied. The #define __linux__ for one is very ugly, it would be much better practice to add new defines for the problematic pieces or rewrite them to work on all systems, it is possible. But who knows japanese enough to reply to this guy? He clearly can't speak english... :p Juho On 7.9.2006, at 18:36, ew...@er... wrote: > -----Original Message----- > From: Kouji Suzuki [mailto:k...@ke...] > Sent: Thursday, September 07, 2006 11:00 AM > To: di...@gu... > Cc: ew...@er... > Subject: Linux IGD was ported to NetBSD. > > Dear Mr. Glover. > > # Because the machine translation is used, # the sentence might be not > correct. > > I succeeded in the movement of LinuxIGD-0.95 on NetBSD-3.0. > Please merge this patch with LinuxIGD. > > In NetBSD, NAT is controlled by using PF. > PF uses the pfctl command usually. > However, this patch is controlled directly by using ioctl. > Perhaps, it corresponds to iptc in linux. > > The thing of the separation of the fire wall function was being > written on > the ToDo page. > This patch considers the thing a little. > > The code shown in linux was described in linux.[ch], the code shown in > NetBSD was described in netbsd.[ch], and the code shown in PF made it > describe in pf.[ch]. > However, it is still imperfect. > > To ensure it, it thinks the code that uses the iptables command to > be should > separate. > However, it decided to avoid it in the fear of the patch's growing. > > Moreover, because the development of libupnp-1.3.1 stops, the patch > to the > library is put in ./etc. > This patch assumes the person who thinks that it uses it with > NetBSD applies > by himself/herself. > Therefore, please append it as it is. > > > Best regards. > > ---------------------- > Kouji Suzuki > mailto:k...@ke... > # It will be automatically discarded if the attached file of # > executable > files or "HTML mail" is transmitted to this mail address. > <linuxigd-0.95-nb.diff.bz2> > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642______________________________ > _________________ > Linux-igd-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-igd-devel |
|
From: <ew...@er...> - 2006-09-07 15:55:57
|
-----Original Message----- From: Kouji Suzuki [mailto:k...@ke...] Sent: Thursday, September 07, 2006 11:00 AM To: di...@gu... Cc: ew...@er... Subject: Linux IGD was ported to NetBSD. Dear Mr. Glover. # Because the machine translation is used, # the sentence might be not correct. I succeeded in the movement of LinuxIGD-0.95 on NetBSD-3.0. Please merge this patch with LinuxIGD. In NetBSD, NAT is controlled by using PF. PF uses the pfctl command usually. However, this patch is controlled directly by using ioctl. Perhaps, it corresponds to iptc in linux. The thing of the separation of the fire wall function was being written on the ToDo page. This patch considers the thing a little. The code shown in linux was described in linux.[ch], the code shown in NetBSD was described in netbsd.[ch], and the code shown in PF made it describe in pf.[ch]. However, it is still imperfect. To ensure it, it thinks the code that uses the iptables command to be should separate. However, it decided to avoid it in the fear of the patch's growing. Moreover, because the development of libupnp-1.3.1 stops, the patch to the library is put in ./etc. This patch assumes the person who thinks that it uses it with NetBSD applies by himself/herself. Therefore, please append it as it is. Best regards. ---------------------- Kouji Suzuki mailto:k...@ke... # It will be automatically discarded if the attached file of # executable files or "HTML mail" is transmitted to this mail address. |
|
From: Nektarios K. P. <npa...@in...> - 2006-08-21 15:19:01
|
Hi, Armijn Hemel wrote: > hi, > >> So, the security issue here is that a malicious control point can add a >> port mapping that let an external entity to connect to your IGD on a >> port and then forward this connection to another external host >> pretending to be your IGD? >> I see only two minor bad issues with this scenario: >> - Unnecessary traffic is passing through your IGD >> - The external host (RemoteHost upnp arg) can be fulled to allow the >> connection based on your IP. > > And basically turn your router in an involuntary onion router. I wouldn't > call that "a minor bad issue" ;) I understand. Bad evaluation/wording on my part. > >> Don't get me wrong. I *do* appreciate your vulnerability report and the >> check should be implemented. >> However, unless we implement e.g. DeviceSecurity service, a malicious >> control point in the LAN can open up whatever port pleases it and be >> upnp correct anyway ;-) > > Yes, unfortunately. UPnP is flawed by design. Too bad there are so many > machines using it... > Yeah, I know, that is why I disabled UPnP on my home router :-( Nevertheless, I *do* care to participate in developing a complete (first) and secure (later) one here :-) Thanks again. > armijn > -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ |
|
From: Armijn H. <ar...@uu...> - 2006-08-20 19:13:39
|
hi, > So, the security issue here is that a malicious control point can add a > port mapping that let an external entity to connect to your IGD on a > port and then forward this connection to another external host > pretending to be your IGD? > I see only two minor bad issues with this scenario: > - Unnecessary traffic is passing through your IGD > - The external host (RemoteHost upnp arg) can be fulled to allow the > connection based on your IP. And basically turn your router in an involuntary onion router. I wouldn't call that "a minor bad issue" ;) > Don't get me wrong. I *do* appreciate your vulnerability report and the > check should be implemented. > However, unless we implement e.g. DeviceSecurity service, a malicious > control point in the LAN can open up whatever port pleases it and be > upnp correct anyway ;-) Yes, unfortunately. UPnP is flawed by design. Too bad there are so many machines using it... armijn -- --------------------------------------------------------------------------- ar...@uu... | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group --------------------------------------------------------------------------- |
|
From: <ju...@ik...> - 2006-08-18 13:46:40
|
On Fri, 18 Aug 2006 12:02:35 +0300 "Nektarios K. Papadopoulos" <npa...@in...> wrote: > So, the security issue here is that a malicious control point can add a > port mapping that let an external entity to connect to your IGD on a > port and then forward this connection to another external host > pretending to be your IGD? > I see only two minor bad issues with this scenario: > - Unnecessary traffic is passing through your IGD > - The external host (RemoteHost upnp arg) can be fulled to allow the > connection based on your IP. How about if someone visits a lan host and forwards some external ports and then route all his spamming and cracking attempts through IGD IP address. I agree this could be done without this vulnerability as well if the malicious user already has access to any lan computers. But it does make it much harder to detect. Just something that comes into my mind. > However, unless we implement e.g. DeviceSecurity service, a malicious > control point in the LAN can open up whatever port pleases it and be > upnp correct anyway ;-) UPnP just sucks in security big time. On the other hand this makes it important to pay some extra attention to security issues. Juho |
|
From: Nektarios K. P. <npa...@in...> - 2006-08-18 09:01:56
|
Hi, Armijn Hemel wrote: > hi, > > [cut] >> I'm not sure I understand the final comment in the Armijn report: >> >> <quote> >> ...,but there is no check to see whether or not NewInternalClient is an >> external IP address. >> </quote> >> >> Why is it important whether or not it is an external IP address. I think >> the right input/output interface is properly set in the iptables >> invocation so having an external IP address in the NewInternalClient >> will just result in an ACCEPT rule that is impossible to trigger. >> What do I miss here? > > I was able to trigger this (repeatedly) with several routers that use > linux-igd. If NewInternalClient is actually an external IP address it will > make a firewalling rule for that external IP address. Connect to the port > that is opened from the outside and your traffic will nicely go through NAT > to the destination port (NewInternalPort if I remember correctly) without a > problem. > > armijn > You are right, when adding a port mappings only the 'in' interface is set to the 'WAN' interface of the IGD in the iptables rule. The 'out' interface of the rule is set to 'any'. I intend add the check anyway, but let me continue the discussion: So, the security issue here is that a malicious control point can add a port mapping that let an external entity to connect to your IGD on a port and then forward this connection to another external host pretending to be your IGD? I see only two minor bad issues with this scenario: - Unnecessary traffic is passing through your IGD - The external host (RemoteHost upnp arg) can be fulled to allow the connection based on your IP. Don't get me wrong. I *do* appreciate your vulnerability report and the check should be implemented. However, unless we implement e.g. DeviceSecurity service, a malicious control point in the LAN can open up whatever port pleases it and be upnp correct anyway ;-) -- ______________________________________________________________ Nektarios K. Papadopoulos Senior Engineer Software Engineering Group inAccess Networks 95A Pentelis Avenue. Tel : +30-210-6837640 152 34 Halandri Athens Fax : +30-210-6899504 ______________________________________________________________ |
|
From: <ju...@ik...> - 2006-08-16 06:49:57
|
On Mon, 14 Aug 2006 16:55:50 +0300 "Nektarios K. Papadopoulos"
<npa...@in...> wrote:
> >> I don't remember what the "harmonizing" concept is. Juho could you
> explain?
> >
> > IIRC, this was converging on the "upnpd" name, rather than an
> > inconsistent set of names from init script, binary, UPnP service name
> > etc.
>
> Ok, I totally agree with this. However I prefer upnp-igd as in my other
> patch ("Building enhancement and a new name" [1]). Although it is
> rather
> established, I find "upnpd" to be too general as if we expect linux-igd
> to be the only upnp daemon in a system ;-)
Yes, the executable name is one issue, I agree upnp-igd or something even better
would be better than upnpd. IGD is just one area of upnp so maybe it's too
general name to give unless we want IGD to be much more general upnp daemon. But
my main reason for harmonization was the complaining about "linux-igd virus
taking over my windows xp network connection". It should be very clear from the
visible name that a) linux-igd is not a virus and b) linux-igd is not running on
client computers.
No one had updated the website when doing 0.95 release by the way. I wrote a
small entry there, hopefully it will give better image for visitors. But the
situation looks very nice now, I should also try to get some time for some
cleanups. And I can vote subversion as well, just don't know how sourceforge's
subversion situation is doing currently.
Cheers,
Juho
|
|
From: Nektarios K. P. <npa...@in...> - 2006-08-14 13:55:10
|
Hi Daniel,
Daniel J Blueman wrote:
> Hi Nektarios,
>
> On 14/08/06, Nektarios K. Papadopoulos <npa...@in...> wrote:
> [snip]
>>> Following this, I'd like to get some other security-related items
>>> tightened up and I have a patch half-cooked for item #1 - this should
>>> take a couple of weeks, then after a couple of weeks of code being
>>> tested to some degree, perhaps a grand 1.0 release?
>
>> I guess you'll finish item #1 on your own. What about #2 (security
>> related issues). Could you elaborate more, can you split the work to
>> pieces so others can help? I could spent some time on this if you
>> provide some more details and be sure I don't do duplicate work.
>
> Yes, no problem fixing the interface byte counter bug.
>
> See my next email on the security stuff - it's worthwhile for one on it's own.
>
>>> Following this, it would be great to get Nektarios's excellent patches
>>> in and iron out any issues; I've seen at least one potential one,
>>> which I'll raise separately
>
> See below.
>
>>> - (I like the "harmonizing" concept I
>>> think Juho mentioned) and release version 1.2/1.5/2.0 depending on how
>>> significant our renewed energy and redefined image is.
>> Thanks for your kind comment. Please raise the issues related to my
>> patches as soon as possible, so I can fix them ;-)
>> Do you also think I need to split the "Layer3Forwarding and minor
>> enhancements" patch into smaller patches or is it ok as is ?
>
> It would be great if you could split the patch, so I can merge them
> separately. With the Layer3Forwarding + enhancements patch, I've
> started to see "TimerThreadRemove failed!" messages, which weren't
> there previously - I don't see anything against merging some or all of
> the minor enhancements for 1.0 if they aren't causing this.
I believe my changes should not cause the "TimerThreadRemove failed!". I
think I've seen it occasionally when running without my patch. I'll
check again for this.
Anyway, regarding splitting the patch. Since all changes are practically
in gatedevice.c, I'm not sure I can create patches that can be accepted
rejected independently.
I'll have a first patch that just defines ActionError(...). All other
patches would require this to be applied since I'm using ActionError all
over :-).
>
>> I don't remember what the "harmonizing" concept is. Juho could you explain?
>
> IIRC, this was converging on the "upnpd" name, rather than an
> inconsistent set of names from init script, binary, UPnP service name
> etc.
Ok, I totally agree with this. However I prefer upnp-igd as in my other
patch ("Building enhancement and a new name" [1]). Although it is rather
established, I find "upnpd" to be too general as if we expect linux-igd
to be the only upnp daemon in a system ;-)
>
> Thanks for your help!
Glad to be able to help ;-)
[1]http://sourceforge.net/tracker/index.php?func=detail&aid=1511242&group_id=52728&atid=467823
--
Nektarios K. Papadopoulos
inAccess Networks
|
|
From: Armijn H. <ar...@uu...> - 2006-08-14 13:08:56
|
hi, [cut] > I'm not sure I understand the final comment in the Armijn report: > > <quote> > ...,but there is no check to see whether or not NewInternalClient is an > external IP address. > </quote> > > Why is it important whether or not it is an external IP address. I think > the right input/output interface is properly set in the iptables > invocation so having an external IP address in the NewInternalClient > will just result in an ACCEPT rule that is impossible to trigger. > What do I miss here? I was able to trigger this (repeatedly) with several routers that use linux-igd. If NewInternalClient is actually an external IP address it will make a firewalling rule for that external IP address. Connect to the port that is opened from the outside and your traffic will nicely go through NAT to the destination port (NewInternalPort if I remember correctly) without a problem. armijn -- --------------------------------------------------------------------------- ar...@uu... | http://www.uulug.nl/ | UULug: Utrecht Linux Users Group --------------------------------------------------------------------------- |
|
From: Nektarios K. P. <npa...@in...> - 2006-08-14 13:02:07
|
Daniel J Blueman wrote: > With 0.95 out, there are some security issues that need to be addressed. > > Armijn Hemel has pointed out some areas he was able to exploit (see > http://www.upnp-hacks.org/stacks.html#linux-igd). > > The security update to always store IP addresses in inaddr structures, > rather than (unbounded) strings isn't much work overall, so I can get > a patch in for this. > > There does need to be a check through the code paths to ensure > requests are correctly validated, and to address some of the issues > that Armijn has raised. > > Any thoughts? In the update Layer3Forwarding patch, I added a check for the protocol type in the AddPortMapping handling code. I also have in a TODO comment the checks for the rest of the input arguments. Regarding the check for a valid NewInternalClient/NewRemoteHost arguments do you think a check for a valid IP string is sufficient or do we need to support dns look up? I think the spec permits an IGD device not to accept hostname for these arguments. I can fill the missing parts for: isBoolean(...) isUI4(...) isUI2(...) isAddress(...) although I think the libupnp itself is better place to implement at least the first three. I'm not sure I understand the final comment in the Armijn report: <quote> ...,but there is no check to see whether or not NewInternalClient is an external IP address. </quote> Why is it important whether or not it is an external IP address. I think the right input/output interface is properly set in the iptables invocation so having an external IP address in the NewInternalClient will just result in an ACCEPT rule that is impossible to trigger. What do I miss here? -- Nektarios K. Papadopoulos inAccess Networks |
|
From: Daniel J B. <dan...@gm...> - 2006-08-14 12:21:09
|
With 0.95 out, there are some security issues that need to be addressed. Armijn Hemel has pointed out some areas he was able to exploit (see http://www.upnp-hacks.org/stacks.html#linux-igd). The security update to always store IP addresses in inaddr structures, rather than (unbounded) strings isn't much work overall, so I can get a patch in for this. There does need to be a check through the code paths to ensure requests are correctly validated, and to address some of the issues that Armijn has raised. Any thoughts? -- Daniel J Blueman |
|
From: Daniel J B. <dan...@gm...> - 2006-08-14 12:13:03
|
Hi Nektarios, On 14/08/06, Nektarios K. Papadopoulos <npa...@in...> wrote: [snip] > > Following this, I'd like to get some other security-related items > > tightened up and I have a patch half-cooked for item #1 - this should > > take a couple of weeks, then after a couple of weeks of code being > > tested to some degree, perhaps a grand 1.0 release? > I guess you'll finish item #1 on your own. What about #2 (security > related issues). Could you elaborate more, can you split the work to > pieces so others can help? I could spent some time on this if you > provide some more details and be sure I don't do duplicate work. Yes, no problem fixing the interface byte counter bug. See my next email on the security stuff - it's worthwhile for one on it's own. > > Following this, it would be great to get Nektarios's excellent patches > > in and iron out any issues; I've seen at least one potential one, > > which I'll raise separately See below. > > - (I like the "harmonizing" concept I > > think Juho mentioned) and release version 1.2/1.5/2.0 depending on how > > significant our renewed energy and redefined image is. > Thanks for your kind comment. Please raise the issues related to my > patches as soon as possible, so I can fix them ;-) > Do you also think I need to split the "Layer3Forwarding and minor > enhancements" patch into smaller patches or is it ok as is ? It would be great if you could split the patch, so I can merge them separately. With the Layer3Forwarding + enhancements patch, I've started to see "TimerThreadRemove failed!" messages, which weren't there previously - I don't see anything against merging some or all of the minor enhancements for 1.0 if they aren't causing this. > I don't remember what the "harmonizing" concept is. Juho could you explain? IIRC, this was converging on the "upnpd" name, rather than an inconsistent set of names from init script, binary, UPnP service name etc. Thanks for your help! -- Daniel J Blueman |
|
From: Nektarios K. P. <npa...@in...> - 2006-08-14 10:07:47
|
Sorry for not replying earlier, I was on vacations the last 2 weeks. Daniel J Blueman wrote: > I've been testing and committing some updates to the project lately > and wanted to discuss release plans. > > So far, there are a few items I'm aware of: > > 1. connection data counters do not work (bug) > 2. use of unbounded strings, unchecked calls, ip address strings and > other potential security-related things - including memory (valgrind) > bugs, which I've fixed most non-subtle ones already > 3. outstanding patches > 4. subversion migration (?) > > It would be good to do a 0.95 release, as-is. At least people can get > something officially updated. 0.95 is already out now, and it's great to have something officially versioned out for people to use after all this time working from CVS-HEAD. > > Following this, I'd like to get some other security-related items > tightened up and I have a patch half-cooked for item #1 - this should > take a couple of weeks, then after a couple of weeks of code being > tested to some degree, perhaps a grand 1.0 release? I guess you'll finish item #1 on your own. What about #2 (security related issues). Could you elaborate more, can you split the work to pieces so others can help? I could spent some time on this if you provide some more details and be sure I don't do duplicate work. > > Following this, it would be great to get Nektarios's excellent patches > in and iron out any issues; I've seen at least one potential one, > which I'll raise separately - (I like the "harmonizing" concept I > think Juho mentioned) and release version 1.2/1.5/2.0 depending on how > significant our renewed energy and redefined image is. Thanks for your kind comment. Please raise the issues related to my patches as soon as possible, so I can fix them ;-) Do you also think I need to split the "Layer3Forwarding and minor enhancements" patch into smaller patches or is it ok as is ? I don't remember what the "harmonizing" concept is. Juho could you explain? > > The route to 1.0 needn't take as long this I mention, but it's good to > not have to rush. I was looking at subversion migration in the future, > since CVS is a pain without setting up the SSH keys correctly and if > you don't have full net access. > > What do you guys think? +1 for subversion migration. > > Dan Thank you for your efforts. -- Nektarios K. Papadopoulos inAccess Networks |
|
From: Daniel J B. <dan...@gm...> - 2006-08-13 22:47:21
|
If any of you guys have come across patches/improvements/etc to linuxigd which are outside the patch tickets here, then please feel free to drop them in, or pointers to them; now is a good time. I'll get some fixes in that I've been working - fixing the interface byte counters and some security ones I need to write yet and contribute any worthwhile non-intrusive patches we can find. Next stop 1.0! (Intrusive patches after 1.0) Dan -- Daniel J Blueman |
|
From: Daniel J B. <dan...@gm...> - 2006-08-13 22:39:00
|
LinuxIGD 0.95 has been released with a host of security and bug fixes - see the CHANGELOG file in the release for the list of more recent changes. The next release of 1.0 will focus on further security and bug fixes, due around August/November 2006. Please open feature requests, patches and bug reports via the project tickets to raise any suggestions or issues - posting messages on the forums or mailing lists won't get as noticed ;-) . Thanks, Daniel -- Daniel J Blueman |
|
From: Daniel J B. <dan...@gm...> - 2006-08-09 22:48:38
|
Hi Juho and (all CC'd), This sounds like a good post-1.0 task, when there is time to make some larger changes. Thanks for the feedback - I'll get a 0.95 release out the door soon, then work on some security/robustness improvements for the 1.0 release. As always, feedback and ideas are welcome along the way ;-) . Dan On 09/08/06, Juho V=E4h=E4-Herttua <juh...@tk...> wrote: > Hi, > > I'm back and I think automake/autotools support is very welcome. I > had some small scripts together earlier on but they were in no way > finished (didn't install the library in right place) and didn't get > committed. So I would be all for some better build system but other > opinions are of course still welcome. And I think Daniel has a good > list of things to do so far after the 0.95 gets out. > > Just my two euro cents. > > > Juho > > > On 8.8.2006, at 19:43, Rosfran Borges wrote: > > > > It's nice your initiative, Blueman. Among these items you noted, > > there are another things we can priorize too, like the 'automake/ > > autotools' support on compilation and library dependencies. I can > > do this, if everybody agree with it: so we can use it to > > generate .deb packages. > > > > []'s > > Rosfran Borges > > > > On 8/7/06, Daniel J Blueman <dan...@gm...> wrote: Hi guys, > > > > I sent this message [1] to the linux-igd devel list, but had not > > response yet. If no-one objects, I'll cut a 0.95 release over the next > > few days, then move on to the next steps below. > > > > Feedback is welcome - please CC lin...@li..., > > so everyone gets the info (eventually). > > > > Thanks, > > Daniel > > > > --- [1] > > > > I've been testing and committing some updates to the project lately > > and wanted to discuss release plans. > > > > So far, there are a few items I'm aware of: > > > > 1. connection data counters do not work (bug) > > 2. use of unbounded strings, unchecked calls, ip address strings and > > other potential security-related things - including memory (valgrind) > > bugs, which I've fixed most non-subtle ones already > > 3. outstanding patches > > 4. subversion migration (?) > > > > It would be good to do a 0.95 release, as-is. At least people can get > > something officially updated. > > > > Following this, I'd like to get some other security-related items > > tightened up and I have a patch half-cooked for item #1 - this should > > take a couple of weeks, then after a couple of weeks of code being > > tested to some degree, perhaps a grand 1.0 release? > > > > Following this, it would be great to get Nektarios's excellent patches > > in and iron out any issues; I've seen at least one potential one, > > which I'll raise separately - (I like the "harmonizing" concept I > > think Juho mentioned) and release version 1.2/1.5/2.0 depending on how > > significant our renewed energy and redefined image is. > > > > The route to 1.0 needn't take as long this I mention, but it's good to > > not have to rush. I was looking at subversion migration in the future, > > since CVS is a pain without setting up the SSH keys correctly and if > > you don't have full net access. > > > > What do you guys think? > > -- > > Daniel J Blueman > > > > --=20 Daniel J Blueman |
|
From: <juh...@tk...> - 2006-08-09 16:29:04
|
Hi, I'm back and I think automake/autotools support is very welcome. I had some small scripts together earlier on but they were in no way finished (didn't install the library in right place) and didn't get committed. So I would be all for some better build system but other opinions are of course still welcome. And I think Daniel has a good list of things to do so far after the 0.95 gets out. Just my two euro cents. Juho On 8.8.2006, at 19:43, Rosfran Borges wrote: > > It's nice your initiative, Blueman. Among these items you noted, > there are another things we can priorize too, like the 'automake/ > autotools' support on compilation and library dependencies. I can > do this, if everybody agree with it: so we can use it to > generate .deb packages. > > []'s > Rosfran Borges > > On 8/7/06, Daniel J Blueman <dan...@gm...> wrote: Hi guys, > > I sent this message [1] to the linux-igd devel list, but had not > response yet. If no-one objects, I'll cut a 0.95 release over the next > few days, then move on to the next steps below. > > Feedback is welcome - please CC lin...@li..., > so everyone gets the info (eventually). > > Thanks, > Daniel > > --- [1] > > I've been testing and committing some updates to the project lately > and wanted to discuss release plans. > > So far, there are a few items I'm aware of: > > 1. connection data counters do not work (bug) > 2. use of unbounded strings, unchecked calls, ip address strings and > other potential security-related things - including memory (valgrind) > bugs, which I've fixed most non-subtle ones already > 3. outstanding patches > 4. subversion migration (?) > > It would be good to do a 0.95 release, as-is. At least people can get > something officially updated. > > Following this, I'd like to get some other security-related items > tightened up and I have a patch half-cooked for item #1 - this should > take a couple of weeks, then after a couple of weeks of code being > tested to some degree, perhaps a grand 1.0 release? > > Following this, it would be great to get Nektarios's excellent patches > in and iron out any issues; I've seen at least one potential one, > which I'll raise separately - (I like the "harmonizing" concept I > think Juho mentioned) and release version 1.2/1.5/2.0 depending on how > significant our renewed energy and redefined image is. > > The route to 1.0 needn't take as long this I mention, but it's good to > not have to rush. I was looking at subversion migration in the future, > since CVS is a pain without setting up the SSH keys correctly and if > you don't have full net access. > > What do you guys think? > -- > Daniel J Blueman > |
|
From: Rosfran B. <ro...@gm...> - 2006-08-08 16:43:56
|
It's nice your initiative, Blueman. Among these items you noted, there are another things we can priorize too, like the 'automake/autotools' support on compilation and library dependencies. I can do this, if everybody agree with it: so we can use it to generate .deb packages. []'s Rosfran Borges On 8/7/06, Daniel J Blueman <dan...@gm...> wrote: > > Hi guys, > > I sent this message [1] to the linux-igd devel list, but had not > response yet. If no-one objects, I'll cut a 0.95 release over the next > few days, then move on to the next steps below. > > Feedback is welcome - please CC lin...@li..., > so everyone gets the info (eventually). > > Thanks, > Daniel > > --- [1] > > I've been testing and committing some updates to the project lately > and wanted to discuss release plans. > > So far, there are a few items I'm aware of: > > 1. connection data counters do not work (bug) > 2. use of unbounded strings, unchecked calls, ip address strings and > other potential security-related things - including memory (valgrind) > bugs, which I've fixed most non-subtle ones already > 3. outstanding patches > 4. subversion migration (?) > > It would be good to do a 0.95 release, as-is. At least people can get > something officially updated. > > Following this, I'd like to get some other security-related items > tightened up and I have a patch half-cooked for item #1 - this should > take a couple of weeks, then after a couple of weeks of code being > tested to some degree, perhaps a grand 1.0 release? > > Following this, it would be great to get Nektarios's excellent patches > in and iron out any issues; I've seen at least one potential one, > which I'll raise separately - (I like the "harmonizing" concept I > think Juho mentioned) and release version 1.2/1.5/2.0 depending on how > significant our renewed energy and redefined image is. > > The route to 1.0 needn't take as long this I mention, but it's good to > not have to rush. I was looking at subversion migration in the future, > since CVS is a pain without setting up the SSH keys correctly and if > you don't have full net access. > > What do you guys think? > -- > Daniel J Blueman > |
|
From: Eric W. <eb...@er...> - 2006-08-08 10:51:22
|
Sounds good to me. Eric >-----Original Message----- >From: Daniel J Blueman [mailto:dan...@gm...] >Sent: Monday, August 07, 2006 8:09 AM >To: and...@us...; >ew...@us...; hfm...@us...; >ju...@us...; kra...@us...; >mhy...@us...; my...@us...; >ro...@us... >Cc: lin...@li... >Subject: [linux-igd] Release goals and roadmap... > >Hi guys, > >I sent this message [1] to the linux-igd devel list, but had >not response yet. If no-one objects, I'll cut a 0.95 release >over the next few days, then move on to the next steps below. > >Feedback is welcome - please CC lin...@li..., >so everyone gets the info (eventually). > >Thanks, > Daniel > >--- [1] > >I've been testing and committing some updates to the project >lately and wanted to discuss release plans. > >So far, there are a few items I'm aware of: > > 1. connection data counters do not work (bug) 2. use of >unbounded strings, unchecked calls, ip address strings and >other potential security-related things - including memory >(valgrind) bugs, which I've fixed most non-subtle ones already > 3. outstanding patches 4. subversion migration (?) > >It would be good to do a 0.95 release, as-is. At least people >can get something officially updated. > >Following this, I'd like to get some other security-related >items tightened up and I have a patch half-cooked for item #1 >- this should take a couple of weeks, then after a couple of >weeks of code being tested to some degree, perhaps a grand 1.0 release? > >Following this, it would be great to get Nektarios's excellent >patches in and iron out any issues; I've seen at least one >potential one, which I'll raise separately - (I like the >"harmonizing" concept I think Juho mentioned) and release >version 1.2/1.5/2.0 depending on how significant our renewed >energy and redefined image is. > >The route to 1.0 needn't take as long this I mention, but it's >good to not have to rush. I was looking at subversion >migration in the future, since CVS is a pain without setting >up the SSH keys correctly and if you don't have full net access. > >What do you guys think? >-- >Daniel J Blueman |
|
From: <and...@us...> - 2006-08-08 09:06:41
|
Daniel J Blueman wrote: > Hi guys, > > I sent this message [1] to the linux-igd devel list, but had not > response yet. If no-one objects, I'll cut a 0.95 release over the next > few days, then move on to the next steps below. > > Feedback is welcome - please CC lin...@li..., > so everyone gets the info (eventually). > This is a most welcome initiative, it is so nice to see linux-igd come to life again. I have absolutely no objection to anything you proposed. Looking forward to the release. Cheers /anders |
|
From: Daniel J B. <dan...@gm...> - 2006-08-07 12:08:49
|
Hi guys, I sent this message [1] to the linux-igd devel list, but had not response yet. If no-one objects, I'll cut a 0.95 release over the next few days, then move on to the next steps below. Feedback is welcome - please CC lin...@li..., so everyone gets the info (eventually). Thanks, Daniel --- [1] I've been testing and committing some updates to the project lately and wanted to discuss release plans. So far, there are a few items I'm aware of: 1. connection data counters do not work (bug) 2. use of unbounded strings, unchecked calls, ip address strings and other potential security-related things - including memory (valgrind) bugs, which I've fixed most non-subtle ones already 3. outstanding patches 4. subversion migration (?) It would be good to do a 0.95 release, as-is. At least people can get something officially updated. Following this, I'd like to get some other security-related items tightened up and I have a patch half-cooked for item #1 - this should take a couple of weeks, then after a couple of weeks of code being tested to some degree, perhaps a grand 1.0 release? Following this, it would be great to get Nektarios's excellent patches in and iron out any issues; I've seen at least one potential one, which I'll raise separately - (I like the "harmonizing" concept I think Juho mentioned) and release version 1.2/1.5/2.0 depending on how significant our renewed energy and redefined image is. The route to 1.0 needn't take as long this I mention, but it's good to not have to rush. I was looking at subversion migration in the future, since CVS is a pain without setting up the SSH keys correctly and if you don't have full net access. What do you guys think? -- Daniel J Blueman |
|
From: Daniel J B. <dan...@gm...> - 2006-08-02 20:36:11
|
I've been testing and committing some updates to the project lately and wanted to discuss release plans. So far, there are a few items I'm aware of: 1. connection data counters do not work (bug) 2. use of unbounded strings, unchecked calls, ip address strings and other potential security-related things - including memory (valgrind) bugs, which I've fixed most non-subtle ones already 3. outstanding patches 4. subversion migration (?) It would be good to do a 0.95 release, as-is. At least people can get something officially updated. Following this, I'd like to get some other security-related items tightened up and I have a patch half-cooked for item #1 - this should take a couple of weeks, then after a couple of weeks of code being tested to some degree, perhaps a grand 1.0 release? Following this, it would be great to get Nektarios's excellent patches in and iron out any issues; I've seen at least one potential one, which I'll raise separately - (I like the "harmonizing" concept I think Juho mentioned) and release version 1.2/1.5/2.0 depending on how significant our renewed energy and redefined image is. The route to 1.0 needn't take as long this I mention, but it's good to not have to rush. I was looking at subversion migration in the future, since CVS is a pain without setting up the SSH keys correctly and if you don't have full net access. What do you guys think? Dan -- Daniel J Blueman |
2 messages has been excluded from this view by a project administrator.
