The SHA256 sums and LENGTH's on squid port are wrong
Hi, I just downloaded squid to audit it and found that OpenBSD has wrong checksums. http://www.squid-cache.org/Versions/v6/squid-6.7.tar.xz.asc Unless squid-cache.org got hacked, thses are the correct SHA1/MD5 hashsums. (unfortunately no SHA256). pjp@vega$ sha256 -b squid-6.7.tar.xz SHA256 (squid-6.7.tar.xz) = 4U2qTq5Bkl0a4/COZEOaaqowEb3O1oZii43ml9WrhCg= pjp@vega$ sha1 squid-6.7.tar.xz SHA1 (squid-6.7.tar.xz) = 86f55f218e86c91c99887803edb4d9b103dce713 In your ports file the checksums are: root@vega# more distinfo SHA256 (squid-6.7.tar.xz) = D3AeE2m/+rnKNIB1+7lu66Lw53g4KwMx5cj2VB22pC0= SIZE (squid-6.7.tar.xz) = 2562880 Thanks! -peter
fluxbox is coring upon teardown of the X11 server
Hi,
While chasing a X11 keymap issue (where page-up/page-down became
scroll-up/scroll-down), I noticed creations of fluxbox.core files.
My system is 7.2 without patches (none yet), if you need a dmesg I can
provide that to you later.
I then re-oriented myself chasing the fluxbox bug that does this, here
is a traceback:
Core was generated by `fluxbox'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/lib/libpthread.so.26.2...done.
...
(gdb) bt
#0 thrkill () at /tmp/-:3
#1 0x0d0e49e79a9e in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2 0x0d0b92c62e37 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#3
#4 0x0d0b92c98eb2 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#5 0x0d0b92c8c7e4 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#6 0x0d0b92c8cddf in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#7 0x0d0b92c28c42 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#8 0x0d0b92c2987f in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#9 0x0d0b92c5b6fe in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#10 0x0d0b92c5ba4f in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#11 0x0d0e49eb91b1 in _libc___cxa_finalize (dso=0x0)
at /usr/src/lib/libc/stdlib/atexit.c:177
#12 0x0d0e49eb1511 in _libc_exit (status=1)
at /usr/src/lib/libc/stdlib/exit.c:54
---Type to continue, or q to quit---
#13 0x0d0b92c5a931 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#14 0x0d0db6c7acea in _XIOError () from /usr/X11R6/lib/libX11.so.18.0
#15 0x0d0db6c78d45 in _XReply () from /usr/X11R6/lib/libX11.so.18.0
#16 0x0d0db6c6d666 in XQueryTree () from /usr/X11R6/lib/libX11.so.18.0
#17 0x0d0b92c98a69 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#18 0x0d0b92c5c3ac in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#19 0x0d0b92c5bfa6 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#20 0x0d0b92c61f76 in virtual thunk to std::__1::basic_ifstream >::~basic_ifstream() () from /usr/local/bin/fluxbox
#21 0x0d0b92be0302 in ?? () from /usr/local/bin/fluxbox
#22 0x in ?? ()
Current language: auto; currently asm
Now I'm not a c++ programmer (I stuck with C) but I was curious enough if the
similarities outweighed the differences between the two languages. I did not
find any atexit() calls but investigating that it cores on signal 6 caused me
to turn on logging of fluxbox. It said this:
Fluxbox: XIOError: lost connection to display.
So it was fairly easy then to produce this patch (patch-src_fluxbox_cc):
--- src/fluxbox.cc.orig Sun Oct 23 12:09:14 2022
+++ src/fluxbox.cc Sun Oct 23 12:09:33 2022
@@ -162,7 +162,7 @@
int handleXIOErrors(Display* d) {
cerr << "Fluxbox: XIOError: lost connection to display.\n";
-exit(1);
+_exit(1);
}
It's possibly not the right fix, but it prevents the corefile from being
written, which is all I care about. This is why I don't see a need to move
this upstream.
I'm not on the ports mailing list so reply to me directly for any feedback.
Best Regards,
-peter
Re: NEW: net/delphinusdnsd
On Tue, Jul 14, 2020 at 01:00:06AM +, Ricardo wrote: > Minor changes: > > *** Makefile 2020-07-14 01:14:36.450371963 +0100 > --- Makefile 2020-07-14 00:59:54.0 +0100 Thank you Ricardo for the work to get this program into OpenBSD ports! I am the sole author of this program. It really is great that someone cares enough to submit it for me, it was always a dream of mine to have this submitted. I do use this in production on my own servers. Here is an outlook if version 1.4.2 gets submitted for OpenBSD 6.8. I have planned around yearly releases but going to float the 1.5.0 release right after 6.8 comes out, so OpenBSD 6.9 would ultimately see a delphinusdnsd 1.5.X. Features for that are a forwarding mode which has the nice feature of TSIG protection (anything similar to that is only found in BIND). Then the delphinusdsnd 1.6.0 release will likely be released in december 2021. It will have DNS Updates I hope, which are difficult (for me) to implement. So that would be for OpenBSD 7.3 time. That's the maintainership of this program and (far) lookout for version changes. Right now delphinusdnsd defaults its config to /etc, but this submitted port defaults to /var/delphinusdnsd, I'm going to make inroads in version 1.5.0 to have it default to /var/delphinusdnsd without needing to pass it flags to configure. That will all be done before OpenBSD 6.8 comes out. Best Regards, -peter
Re: NEW: Delphinus DNS
On Sat, Mar 07, 2020 at 09:44:03PM +, PiRATA wrote:
> Ping
>
> ? Original Message ?
> On Monday, February 24, 2020 6:03 PM, PiRATA wrote:
>
> > Hey @ports,
> >
> > Delphinus DNS is a non-caching, non-recursing DNS server that serves
> > authoritative answers for A, , CNAME, DNSKEY, DS, MX, NAPTR, NS, NSEC3,
> > NSEC3PARAM, PTR, RRSIG, SOA, SRV, SSHFP, TLSA, and TXT resource records.
> >
> > Homepage: https://delphinusdns.org/
> >
> > Tested on amd64.
> > Comments and testing needed. OK?
Hi,
I was in contact with PiRATA (I'm also the programs author), and we improved
on the Makefile a bit.
I tested installing this on amd64, i386, octeon and macppc. That's all the
archs I have to my avail. It installed in all of them.
I didn't test that they would run, but I tested that outside of the ports
hierarchy and I know they do work on OpenBSD/{amd64,i386,octeon,macppc}.
PiRATA will follow up with an improved Makefile. If someone wants to OK this
that'd be really nice!
Best Regards,
-peter
Re: [Re: XSS vuln in cvsweb]
On Fri, Mar 15, 2019 at 05:22:47PM -0700, Andrew Hewus Fresh wrote: > > I have produced the patch with 'diff -u cvsweb.orig cvsweb' directly in the > > /var/www/cgi-bin directory. Credit goes to Ezio Paglia for finding this XSS > > vuln. Also the cvsweb at openbsd.org is affected and can be checked with: > > I looked this over and updated the patch to be against the port. It > seems to be good and I only found a couple other places that needed to > be escaped, the "stickyvars" section and the tr1/tr2 inputs in doLog, > although r1, r2, tr1 and tr2 are part of "unsafevars" so their content > is pretty limited already. > > It was a pretty quick look so I don't doubt that there are more, and I > didn't actually get a chance to test it out, so hopefully someone else > can. > > > https://cvsweb.openbsd.org/src/sbin/clri/clri.c?f=%22%3E%3Cscript%3Ealert(%27XSS%27)%3C/script%3E > > > > in chrome the XSS check activates immediately, I don't know what firefox > > does. > > With NoScript it throws up a big error saying there was an attempted > XSS, without NoScript it throws up an alert box saying "XSS". > Index: Makefile ... Hi, Thanks for the help! I have applied your patch and it went cleanly (commands were cd /usr/ports/devel/cvsweb; patch -p0 < cvsweb.patch), I then rebuilt the port with "make reinstall" no problem there either. The CGI is the newly built CGI as discovered with ls. A quick test shows that it applied the XSS escapes. Best Regards, -peter
Re: [Re: XSS vuln in cvsweb]
would this help any? https://people.freebsd.org/~scop/cvsweb/ There is subsequent versions. Regards, -peter On 3/15/19 4:05 PM, Ingo Schwarze wrote: Hi, the trouble with cvsweb is that it is important OpenBSD project infrastructure (consider cvsweb.openbsd.org) that has been abandoned upstream 13 years ago, our version is 16 years old, and the port has no maintainer. Does anybody consider it funny to run a software in production that is closely related to version control, but (according to my knowledge) is not currently under version control itself? Given that i'm still using it on bsd.lv, too, i'm willing to host a CVS repo for it and the release tarballs (historic and future) on bsd.lv, pick up upstream maintenance, and also maintain the port. Does that sound reasonable to people round here? If so, does anyone know whether a copy of the original CVS repository that it resided in still exists somewhere? It seems to have vanished from https://svnweb.freebsd.org/base/projects/ ... I don't consider the XSS urgent, but it would of course get fixed in the process. If people wanted, they could test and commit patches to the port beforehand, but i'm not sure it's needed. Yours, Ingo
[Re: XSS vuln in cvsweb]
Hi,
I have have created a patch for cvsweb port that needs review and help in
getting it into the port itself. I'd like to apologize to Marc Espie for
contacting him regarding this port based on his last check-in on this port,
and thanks to Stuart Henderson for directing me here.
The patch changed since my last submission to misc@ and since I am a complete
newbie in perl this would need a pro to look at it whether it's correct.
I have produced the patch with 'diff -u cvsweb.orig cvsweb' directly in the
/var/www/cgi-bin directory. Credit goes to Ezio Paglia for finding this XSS
vuln. Also the cvsweb at openbsd.org is affected and can be checked with:
https://cvsweb.openbsd.org/src/sbin/clri/clri.c?f=%22%3E%3Cscript%3Ealert(%27XSS%27)%3C/script%3E
in chrome the XSS check activates immediately, I don't know what firefox does.
Patch after end of signature and forwarded message:
-peter
- Forwarded message from Stuart Henderson -
Date: Fri, 15 Mar 2019 12:16:06 - (UTC)
From: Stuart Henderson
To: m...@openbsd.org
Subject: Re: XSS vuln in cvsweb
User-Agent: slrn/1.0.2 (OpenBSD)
On 2019-03-15, Peter J. Philipp wrote:
> Hi all,
>
> I have been notified by a wonderful security researcher that my site was
> vulnerable to XSS attacks. The first one was on software I wrote, and the
> second one was on software I got from OpenBSD ports. Not sure if I should
> be writing this to the ports mailing list though.
>
> I have written Marc Espie with a patch that I produced for cvsweb, but
> haven't heard from him in 11 hours so I want to get this out to everyone.
Yes, it should go to the ports mailing list. Check the "maintainer" line
in "pkg_info cvsweb". I don't know why you would send it to espie@.
- End forwarded message -
--- cvsweb.orig Thu Mar 14 18:30:06 2019
+++ cvsweb Fri Mar 15 10:23:05 2019
@@ -998,8 +998,9 @@
if (scalar %tags || $input{only_with_tag}) {
print "\n";
foreach my $var (@stickyvars) {
+ my $tmpvar = htmlquote($input{$var});
print
- "\n"
+ "\n"
if (defined($input{$var})
&& (!defined($DEFAULTVALUE{$var})
|| $input{$var} ne $DEFAULTVALUE{$var})
@@ -2612,7 +2613,7 @@
sprintf(
'%s/%s?annotate=%s%s', $scriptname,
urlencode($where), $_,
- $barequery
+ htmlquote($barequery)
)
);
}
@@ -2625,7 +2626,7 @@
'[select for diffs]',
sprintf(
'%s?r1=%s%s', $scriptwhere,
- $_, $barequery
+ $_,
htmlquote($barequery)
)
);
} else {
@@ -2828,7 +2829,7 @@
foreach (@stickyvars) {
printf('', $_,
- $input{$_})
+ htmlquote($input{$_}))
if (defined($input{$_})
&& ((!defined($DEFAULTVALUE{$_})
|| $input{$_} ne $DEFAULTVALUE{$_}) && $input{$_} ne ""));
@@ -3267,7 +3268,7 @@
join ('', $scriptname,
urlencode($wherepath),
(!$last || $lastslash ? '/' : ''),
- $query,
+ htmlquote($query),
(!$last || $lastslash ? "#dirlist" : "")
));
} else {# do not make a link to the current dir
@@ -3508,6 +3509,7 @@
# Special Characters; RFC 1866
s/&//g;
s/\"//g;
+ s/%22//g;
s///g;
