-12098 patch causes compilation to fail.
I have not yet had a chance to investigate why.
Souce code pushed to the heimdal repsitory on salsa in the debian/jessie
branch.
https://salsa.debian.org/debian/heimdal
--
Brian May
https://linuxpenguins.xyz/brian/
sed (no XX in filename
string), so vulnerable still.
If you want to look at libqb probably worth double checking this in case
I got something wrong/confused :-)
--
Brian May
https://linuxpenguins.xyz/brian/
ly for the 2nd two
CVEs.
--
Brian May
a score of 2.35%
It is also worth noting that there are other potential security issues
with this library, e.g. see
https://github.com/openid/ruby-openid/issues/98
Regards
--
Brian May
/tmp/tigerpsdfmt.psd ; echo $?
1
This same command with the same file works on stretch.
Any ideas?
Regards
--
Brian May
https://linuxpenguins.xyz/brian/
y update to
imagemagick may have introduced some weird regression into the identify
command.
I just tested imagemagick version deb8u12 in Jessie, same problem.
--
Brian May
Brian May writes:
> I just tested imagemagick version deb8u12 in Jessie, same problem.
Exactly the same behaviour with version 6.8.9.9-5. How very odd.
--
Brian May
.
+ * CVE-2019-11027 Avoid SSRF for claimed_id request.
+Patch source: https://github.com/openid/ruby-openid/pull/121
+
+ -- Brian May Wed, 09 Oct 2019 17:00:00 +1100
+
ruby-openid (2.5.0debian-1) unstable; urgency=medium
* Imported Upstream version 2.5.0debian
diff -Nru ruby-openid
is checked, that makes
it impossible for a third party to change the claimed_id URL, rendering
the attack impossible.
I don't claim to be an expert on this however.
--
Brian May
-security; urgency=high
+
+ * Non-maintainer upload by the LTS Team.
+ * CVE-2019-9959
+JPXStream::init function doesn't check for negative values of
+stream length, leading to an Integer Overflow, leading to large
+memory request causing DOS.
+
+ -- Brian May Mon, 14 Oct 2019 17:
It appears if I can work out how to define SPLASH_CMYK for the build,
then I can fix CVE-2019-10871 too. So I will investigate this
possibility.
--
Brian May
Brian May writes:
> It appears if I can work out how to define SPLASH_CMYK for the build,
> then I can fix CVE-2019-10871 too. So I will investigate this
> possibility.
Updated patch.
diff -Nru poppler-0.26.5/debian/changelog poppler-0.26.5/debian/changelog
--- poppler-0.26.5/debian/
Brian May writes:
> It appears if I can work out how to define SPLASH_CMYK for the build,
> then I can fix CVE-2019-10871 too. So I will investigate this
> possibility.
This change broke xpdf, so had to be reverted. I amy look into this
again next month.
--
Brian May
ble upstream solution to #125.
Any opinions?
--
Brian May
10h because they
will include the supplementary work hour done the month before.
=== cut ===
This can happen if you have unexpected urgent work to do when you have
reached your hours for the month. For example a regression in a previous
upload.
--
Brian May
@@
+angular.js (1.2.26-1+deb8u1) jessie-security; urgency=high
+
+ * Non-maintainer upload by the LTS Team.
+ * Fix CVE-2019-14863: properly sanitize xlink:href attribute interoplation.
+
+ -- Brian May Mon, 11 Nov 2019 17:39:43 +1100
+
angular.js (1.2.26-1) unstable; urgency=low
* New
Windows,
before 1. ...)
NOT-FOR-US: Skype
CVE-2005-3266
=== cut ===
--
Brian May
hat I can see.
Hence, I am inclined to think maybe glibc doesn't need to be fixed in
Jessie.
--
Brian May
https://linuxpenguins.xyz/brian/
il, will make sure I check the
correct package tonight.
--
Brian May
Brian May writes:
> Apparently the fix for ibus creates a regression in glibc that must get
> fixed also:
>
> https://gitlab.gnome.org/GNOME/glib/merge_requests/1176
>
> However this patch patches GIO in glibc, and it looks like glibc in
> Jessie (2.19-18+deb8u10) doesn'
e warnings being treated as errors
Makefile:3465: recipe for target 'libgio_2_0_la-gdbusauth.lo' failed
The patch removes a function called "hexencode" and replaces it with
"_g_dbus_hexencode". I wonder if it would be sufficient just to reverse
this bit of the change?
--
Brian May
Brian May writes:
> Emilio Pozuelo Monfort writes:
>
>> I have been looking at this, but building glib with only the two fix commits
>> (not the tests one) makes the build hang on the network-monitor tests. I
>> haven't
>> investigated much yet, but I wonder
Brian May writes:
> My build is still running the tests, but I don't expect any problems as
> the test was getting skipped anyway...
Tests seem to be hanging, on the next test after:
PASS: network-address 37 /gresolver/resolve-address/0
PASS: network-address 38 /gresolver/resolv
ut
the glib2.0 breakage.
--
Brian May
ls.c:2131
#13 0x7736b90b in g_test_run_suite (suite=0x611220) at
/build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:2184
#14 0x7736b941 in g_test_run () at
/build/glib2.0-sBwZ3c/glib2.0-2.42.1/./glib/gtestutils.c:1488
#15 0x00401461 in main (argc=1, argv=0x7fffeb68) at
#/build/glib2.0-sBwZ3c/glib2.0-2.42.1/./gio/tests/network-monitor.c:536
--
Brian May
Brian May writes:
> With the 2nd patch, hangs, I pushed Ctrl-C to abort:
>
> (jessie-amd64-sbuild)brian@silverfish:/$
> /build/glib2.0-sBwZ3c/glib2.0-2.42.1/debian/build/deb/gio/tests/.libs/lt-network-monitor
> -k --tap
> # random seed: R02Sfd80eb1bd64b09d0b63ad8bcdfd
Brian May writes:
> commit 7cba800a84730c9c5843acdd775e42b8c1438edf (HEAD)
> Author: Alexander Larsson
> Date: Mon Jun 1 10:02:47 2015 +0200
This patch decreases the number of errors from 1 to 52.
(jessie-amd64-default)brian@silverfish:~/debian/lts/packages/glib2.0/glib$
gio/test
2 in g_test_run_suite_internal
(suite=suite@entry=0x610220, path=, path@entry=0x773b9fde
"") at gtestutils.c:2131
#15 0x7733bc6b in g_test_run_suite (suite=0x610220) at gtestutils.c:2184
#16 0x7733bca1 in g_test_run () at gtestutils.c:1488
#17 0x00401361 in main (argc=1, argv=0x7fffeab8) at
network-monitor.c:536
(gdb)
--
Brian May
Brian May writes:
> Here is a better stack trace (previous version was picking up system
> version of glib):
Here is an even better version of the even better version of the stack
trace that is actually useful (disabled compile time optimisation)
(gdb) bt
#0 0x772cbd08 in _g_log
; urgency=high
+
+ * Non-maintainer upload by the LTS Team.
+
+ -- Brian May Tue, 04 Feb 2020 17:25:44 +1100
+
ruby-rack-cors (0.2.9-1) unstable; urgency=low
* New upstream release
diff -Nru ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978.patch
ruby-rack-cors-0.2.9/debian/patches/CVE-2019-18978
e substantial time to pull off." - wonder if it even worth
trying to fix this for anything other then unstable+testing.
--
Brian May
e
could lead to silent breakage, which is probably not a better outcome.
--
Brian May
his is the default session backend, others are also available:
https://docs.djangoproject.com/en/3.0/topics/http/sessions/#configuring-sessions
--
Brian May
I am still unclear why Rack has this issue, and not other libraries that
do a similar lookup of an untrusted key value provided by the user in
the database, e.g. Django.
--
Brian May
to make use of this. Or have I
> misunderstood something?
I suspect you are mostly correct.
However how many people would really notice if an attacker made numerous
connections to their website in attempt to exploit this?
--
Brian May
is function 32, we actually get 32 bytes (=256
bits), or 64 digits.
irb(main):007:0> p SecureRandom.hex(1)
"82"
=> "82"
irb(main):006:0> p SecureRandom.hex(2)
"5fad"
=> "5fad"
--
Brian May
t; such as direct lookups in the session database
using the session key?
Also I noticed - and thought interesting - that storing sessions in the
database was considered using rails (not rack being discussed here) was
deprecated in 2012)
http://blog.remarkablelabs.com/2012/12/activerecord-sessionstore-gem-extraction-rails-4-countdown-to-2013
--
Brian May
ut this was only implemented in PHP >=
7.3
https://www.php.net/manual/en/session.configuration.php
--
Brian May
r site, then
the cookie won't be transmitted from the browser and the user will not
have any login session, so damaging stuff using the user's credentials
is not possible.
--
Brian May
now intend to wait a bit and see if I get any responses. If not, I
will mark this security issue as "not vulnerable" in Debian, because it
is not possible to exploit as it is broken.
--
Brian May
I can tell they both a the same vulnerability. Did I miss
something?
--
Brian May
Brian May writes:
> Hugo Lefeuvre writes:
>
>> xcftools:
>>
>> + create a reproducer for CVE-2019-5086 and write a patch (still waiting
>>for some external review).
>> + start to investigate CVE-2019-5087.
>
> I am a bit puzzled, what is the diffe
//github.com/rack/rack/commit/54600771e3c9628c873fb1140b800ebb52f18e70#diff-ec7f0fcff10d701615d85df33fbbd545
Which replaces Memcache with Dalli instead. I have no idea if Dalli has
been appropriately patched to deal with CVE-2019-16782.
--
Brian May
ey
responded with:
> After consideration, the Django Security Team conclude that this is not
> a practical attack vector.
>
> Work on the related hardenings, such as the referenced tickets should
> continue.
I am inclined to think we do not need to worry about patching old
releases for this vulnerability for similar reasons.
--
Brian May
ckage again...
Regards
--
Brian May
https://linuxpenguins.xyz/brian/
> t...@security.debian.org
I think, like it or not, details were already publicly available in the
referenced github issue. From comment posted on 1st March. There is
probably no point trying to keep this secret.
--
Brian May
was a mistake, and keystone should be listed in
security-support-ended?
--
Brian May
https://linuxpenguins.xyz/brian/
>From dla-needed.txt:
> NOTE: 20200505: Patch for CVE-2020-11724 appears to be fairly
> invasible and, alas, no tests. (lamby)
What does invasible mean in this context?
(I think I could guess - but rather not...)
--
Brian May
https://linuxpenguins.xyz/brian/
"Chris Lamb" writes:
> Yes I believe so. Can you go ahead and request to add it there
> whilst you have it open? If not, let me me know and I will go ahead
> with that. I have removed keystone from dla-needed.txt in 18c3371ddc.
Will do so. Probably Monday.
--
Brian May
this security fix - rejecting unbonded connections -
could break stuff also.
--
Brian May
https://linuxpenguins.xyz/brian/
tooth concept, not specific to hog
(which is just one protocol). See:
https://codeitbro.blogspot.com/2017/04/ble-pairing-vs-bonding.html
If you look at hog.c before the upstream commit was applied, it didn't
have any concept of bonded either.
--
Brian May
Brian May writes:
> Looking at commit
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=7d9718cfcc11eaa9d8059e721301cdc00ef8c82e,
> it looks like maybe we should be patching the attio_connected_cb()
> function instead. But this function doesn't appear to have any w
skPlanner - It might
allow us to visualise the required tasks in a cleaner manner.
Also it occurred to me that Python 2 support is disappearing, but the
scripts in security tracker are still Python 3 only (my latest merge
requests have been stalled). Not sure if we need to add this to the TODO
list o
on
> will always return early here.
Oops. Probably obvious I mostly program in Python...
--
Brian May
or suggestions.
This sounds like a good idea to me.
Just need to come up with an appropriate list of tags to represent the
status. e.g. if a particular TODO item is waiting on response from
security team for example.
--
Brian May
I notice that according to DSA-4694, unbound is not supported anymore in
Stretch.
https://www.debian.org/security/2020/dsa-4694
Does this mean we should also mark it as unsupported in Jessie?
--
Brian May
https://linuxpenguins.xyz/brian/
ample,
I would expect it to be executed.
https://snyk.io/vuln/SNYK-JS-JQUERY-569619
--
Brian May
https://linuxpenguins.xyz/brian/
in a different file.
https://github.com/jquery/jquery/blob/d0ce00cdfa680f1f0c38460bc51ea14079ae8b07/src/core/parseHTML.js
--
Brian May
Brian May writes:
> rscript = /)<[^<]*)*<\/script>/gi,
The simplest possible solution would be to update that regexp to allows
white space in the closing tag.
But of course the problem here is that a regexp isn't really the right
tool for parsing HTML content, and it i
n is completely different
in master:
https://github.com/jquery/jquery/blob/9c98e4e86eda857ee063bc48adbc1a11bb5506ee/src/manipulation/buildFragment.js
Will investigate further, in case there is a simple fix.
--
Brian May
Holger Levsen writes:
> On Tue, Jun 09, 2020 at 07:13:03AM +1000, Brian May wrote:
>> I notice that according to DSA-4694, unbound is not supported anymore in
>> Stretch.
>> https://www.debian.org/security/2020/dsa-4694
>> Does this mean we should also mark it as u
nk we agree with each other here :-)
--
Brian May
Brian May writes:
> But... surprise surprise, it looks like buildFragment may be broken:
It looks like this commit might fix that:
https://github.com/jquery/jquery/commit/22ad8723ce07569a9b039c7901f29e86ad14523c
But this is a rather invasive commit. Don't think we should apply it t
Brian May writes:
> I sent a email to Moritz Muehlenhoff, asking why is changed it to
> unsupported, but not got a response yet.
Response was that upstream support has ended the old version unbound,
and it was deemed to risky too backport changes from supported versions
to the old v
n['path'])) {
+ $path = $destination['path'];
+}
$options['query'] = $destination['query'];
$options['fragment'] = $destination['fragment'];
}
=== cut ===
As such, I am inclined to patch the CVE-2020-13662 / SA-CORE-2020-003
issue, but not touch the jquery issue.
Comments?
--
Brian May
https://linuxpenguins.xyz/brian/
Brian May writes:
> Drupal7, in Jessie has 3 security issues:
My proposed changes to drupal7 in Jessie:
diff -Nru drupal7-7.32/debian/changelog drupal7-7.32/debian/changelog
--- drupal7-7.32/debian/changelog 2019-05-20 20:05:42.0 +1000
+++ drupal7-7.32/debian/changelog 2
here that lists
unsupported packages?
--
Brian May
ecurity-tracker-team/security-tracker/-/commit/2e566eb8abcb548cf7020f18e4dce28aabfc5265
--
Brian May
ker/commit/59a9cd9dca3afc830fea869d12baf2f3d7c21126
Should we mark it as ignored in Stretch also? Or maybe the reason (as
given in the commit message when ksh was first removed) was wrong?
https://salsa.debian.org/security-tracker-team/security-tracker/commit/b72cc677e719d37f5f3378d616d9cb53315db927
will fail, and the email will (silently) never get published.
--
Brian May
7f2ccedbd000
mmap(0x7f2ccedc3000, 14688, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f2ccedc3000
close(3)= 0
arch_prctl(ARCH_SET_FS, 0x7f2ccefe5480) = 0
mprotect(0x7f2ccedbd000, 16384, PROT_READ) = 0
mprotect(0x5633d68d1000, 4096, PROT_READ) = 0
mp
00055db50ad5000 in ?? ()
#9 0x55db50aadb15 in ?? ()
#10 0x55db50aae3a4 in ?? ()
#11 0x55db50aefd24 in ?? ()
#12 0x55db50af106c in ?? ()
#13 0x55db50aad792 in ?? ()
#14 0x55db50ad9294 in ?? ()
#15 0x55db50abec72 in ?? ()
#16 0x55db50aa38dd in ?? ()
#17 0x7f2658ae42e1 in __libc_start_main (main=0x55db50aa3650, argc=1,
argv=0x7ffe505157a8, init=, fini=,
rtld_fini=, stack_end=0x7ffe50515798) at ../csu/libc-start.c:291
#18 0x55db50aa368a in ?? ()
--
Brian May
3/sh/pmain.c:45
I am guessing this segfault might be because we are attempting to access
job.freejobs[x] before job.freejobs has been initialised because we
weren't expecting to run jobs yet.
Yes, this appears to be the case:
/*
* initialize the shell
*/
Shell_t *sh_init(register int argc,register char *argv[], Shinit_f userinit)
{
[...]
env_init(shp); /* function that causes the error */
[...]
/* initialize jobs table */
job_clear();
[...]
}
--
Brian May
h
+
+ * Non-maintainer upload by the LTS Team.
+ * Fix CVE-2019-14868: An attacker could use flaw to override or bypass
+environment restrictions to execute shell commands.
+
+ -- Brian May Thu, 16 Jul 2020 07:53:51 +1000
+
ksh (93u+20120801-3.1) unstable; urgency=medium
* Non-maintaine
x27;t make any security uploads to stretch?
On the other hand the security team has marked both these as no-DSA, in
buster meaning maybe I should do the same thing too?
--
Brian May
https://linuxpenguins.xyz/brian/
Roberto C. Sánchez writes:
> On Wed, Aug 12, 2020 at 08:55:43AM +1000, Brian May wrote:
>> I am seriously thinking that slirp from unstable should be ported as is
>> from sid to buster and stretch. This is not a new upstream version, it
>> has bug fixes and security updat
r buster due to certificate errors).
I was wondering if there was an error in my copy of sig_spoof. I
downloaded the source using:
https://dl.packetstormsecurity.net/1905-exploits/SA-20190513-0.txt
And deleted everything before and after the code, so I think it should
be OK.
Any ideas?
--
B
Brian May writes:
> My attempts to run the reproducer program have not been successful, as
> *none* of the signatures validate. Not even the known good case.
I worked it out. The source had:
-BEGIN PGP PUBLIC KEY BLOCK-
mQENBFyeB6MBCAC+X0+7sQkrpg4zjQGj9NQSwPvDV5JjWx
Brian May writes:
> All of the distributions fail (as in the last two tests pass when they
> should now), but bullseye at least fixes one of the failures. So it
> looks like this was incorrectly marked as fixed (note bulleye and sid
> have the same version of this package).
I filled
Brian May writes:
> Brian May writes:
>
>> All of the distributions fail (as in the last two tests pass when they
>> should now), but bullseye at least fixes one of the failures. So it
>> looks like this was incorrectly marked as fixed (note bulleye and sid
>>
this.
--
Brian May
diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog
--- golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/d
n include it in the message in the first place. But the fact it is
included, and it could confuse programs and/or humans if it is altered.
So the value of this header should be validated.
--
Brian May
library.
Yes, it probably should have been two separate CVEs. Having two distinct
issues in one CVE gets confusing when only one issue gets resolved.
If I understand this correctly, I believe this part was resolved.
--
Brian May
was marked as minor for golang-1.7 in Stretch, probably
also should be marked as minor for golang-golang-x-net-dev also...
--
Brian May
I think.
I am a bit disappointed actually that the CheckDetachedSignature()
doesn't return the hash used. It means that the calling application only
has access to the insecure value that cannot be trusted.
--
Brian May
g, bytes.NewBuffer(b.Bytes),
b.ArmoredSignature.Body)
b.Headers has the header we need to check, but we only pass the body
b.Bytes and the signature b.ArmoredSignature.Body. As in the headers
aren't covered by the signature (I assume there is a good reason...).
Does this make sense now?
--
Brian May
Attached is my patch for golang-go.crypto which I intend to upload
tomorrow for:
* CVE-2019-11840
* CVE-2019-11841
I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can
cause a panic - however I feel this is not really a security issue.
--
Brian May
diff -Nru golang-go.crypto
Utkarsh Gupta writes:
> On Mon, Oct 5, 2020 at 3:03 AM Brian May wrote:
>> I also had a look at CVE-2020-9283 (no DSA) - an invalid public key can
>> cause a panic - however I feel this is not really a security issue.
>
> But still, in case you can include a fix fo
pass, even without
openssh-server installed, so I think this is good to go.
--
Brian May
diff -Nru golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog golang-go.crypto-0.0~git20170407.0.55a552f+REALLY.0.0~git20161012.0.5f31782/debian/changelog
--- go
I have no idea what is wrong here, or why it is fixated on a commit that
is 2 commits behind master...
--
Brian May
--- Begin Message ---
The error message was:
reference to unknown bug DLA-0001-1
reference to unknown bug DLA-0002-1
reference to unknown bug DLA-0003-1
reference to unknown bug
Emilio Pozuelo Monfort writes:
> Have you checked if any rdeps need to be rebuilt?
No. I imagine there might be some. How do I check? I can't remember
right now how to check reverse build depends.
--
Brian May
l which ones need rebuilding? Maybe just the ones without
the 'golang-` prefix?
How do I rebuild? Do I need to upload a new version?
--
Brian May
lise another limitation in the above list. It
probably won't mention, for example, packages that build depend on
golang-github-pkg-sftp-dev which depends on golang-golang-x-crypto-dev.
--
Brian May
linux-gnu/src/golang.org/x/crypto/ocsp/ocsp.go
This looks like a source file.
Wonder if it is possible to extract a list of all source files that were
used to build acmetool...
So far not getting anywhere with "readelf". But maybe "strings" might be
sufficient.
--
Brian May
Brian May writes:
> Package: acmetool
> Package: chasquid
> Package: coyim
> Package: go-wire
> Package: gocryptfs
> Package: golang-github-azure-azure-sdk-for-go
> Package: golang-github-azure-go-autorest
> Package: golang-github-azure-go-ntlmssp
> Package: golang-git
Brian May writes:
> This produced the following output to STDOUT:
>
> === cut ===
> obfs4proxy salsa20
> packer ssh/keys
> rclone salsa20
> restic ssh/keys
> snapd salsa20
> === cut ===
snapd seems to reproduce test failures, even without my security
updates. :
Brian May writes:
> What is the process for rebuilding these in stretch LTS? Do I need to
> add entries to dla-needed.txt and claim these entries?
I might need help here:
=== cut ===
Debian FTP Masters (28 mins. ago) ()
Subject: rclone_1.35-1+deb8u1_amd64.changes REJECTED
e. Waiting a response.
--
Brian May
Brian May writes:
> I have contacted ftp-master concerning rclone. Waiting a response.
Still no response. I submitted a bug report:
https://bugs.debian.org/974877
--
Brian May
here, please help.
I have a similar issue. I opened up a bug report:
https://bugs.debian.org/974877
I suggest you do they same. At least with the bug report there is a
formal public record of the pending request.
--
Brian May
1 - 100 of 527 matches
Mail list logo
