Re: Compiled list (STIG for Debian)
On 3/2/22 10:54, Jeremiah C. Foster wrote: Cannot speak for it's provenance, but there's this; https://github.com/hardenedlinux/STIG-4-Debian Jeremiah, Thanks, that actually looks like more of an SRR (System Readiness Review[0]) evaluation checker for applicable STIGs. As it states, it uses the RHEL7 STIG as a baseline for the tests. While old (2017), it might still prove useful if it can identify CAT I issues quickly with few false negatives as a *starting point* --stephen [0] i think DISA stopped making these scripts due to the burden of keeping them upto date. 3rd parties now do that for
Re: Compiled list
On 3/2/22 07:43, Paul Tagliamonte wrote:
STIGs are maintained by DISA, not by Debian
Paul
On Wed, Mar 2, 2022 at 9:42 AM Stephanie Hall mailto:sh...@oteemo.com>> wrote:
Good morning,
Do you have an excel version of a STIG for Debian 9 & 10 that you would be
willing to share?
Thank you in advance!
The DISA STIGviewer (a Java app that runs just find on Debian), can import a
STIG file and export to CSV
https://public.cyber.mil/stigs/srg-stig-tools/
However, there is no STIG specific to Debian that i'm aware of.
Your best bet is referencing the Ubuntu ones:
U_CAN_Ubuntu_{18-04,20-04}_LTS_V.._STIG.zip
--stephen
Re: DSA-3708-1 mat -- security update (What are MAT users to do)?
> On Sun, Nov 13, 2016 at 5:47 AM, intrigeri <intrig...@debian.org> wrote: > Robert Haist: > > For PDFs you can use exiftool from the libimage-exiftool-perl to remove > > metadata: > > exiftool -all= example.pdf > > This works for me. > > Does this address the problem (metadata in embedded images) that > triggered us from removing this functionality from MAT? Assuming the documentation is correct, the manpage for exiftool states: >3) Changes to PDF files are reversible because the original information is never actually deleted from the file. > So ExifTool alone may not be used to securely edit metadata in PDF files. that sounds like a "NO". :-( --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Feature request: security-tracker website: add data columns indicating affected releases and/or issue creation time
https://security-tracker.debian.org/tracker/data/fake-names "Automatically generated issue names" could really benefit by having additional data columns such as: - date of issue creation (unfortunately, the full info page doesn't even seem to have that) - affected Debian releases "Packages that may be vulnerable but need to be checked (undetermined issues)" section at least has affected releases listed. This would help users when scanning to quickly see if something might look relevant. But in general, the specific issue pages would really benefit by creation date addition. (yeah, i can click on the associated bug-reports to see times, but it'd be nice to have it immediately accessible) thanks, --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Re: Security EOL within Debian Stable
On Wed, Feb 4, 2015 at 6:49 PM, Michael Gilbert mgilb...@debian.org wrote: On Wed, Feb 4, 2015 at 8:09 PM, Stephen Dowdy wrote: So, if a user installs said package, but fails to notice any EOL DSA on it, the package gets left in place in a potentially VULNERABLE state. I.E. if a known exploit comes out, and the package is still installed, the end-user could get a nasty surprise thinking that because they've added security support to apt-sources and regularly update, that they are protected. This is a non-optimal and undesired end-result. The debian-security-support package somewhat addresses those concerns [0], but it is not currently installed by default. There was some discussion to make that happen, but hasn't been followed through. Ah, that's useful to know, and that would be a a reasonable solution. However, that package depends upon being current and having the endedlimited support db files updated $ check-support-status -V version 2014.09.07 $ grep chromium /usr/share/debian-security-support/* || echo Chromium not listed Chromium not listed It's been less than a week since 'chromium' support was EOL'd, so hopefully soon 'debian-security-support' will get that updated info. To me, that's a satisfactory solution, again, depending upon it being maintained. I'll ensure that our default FAI config includes that package from here out. (additionally, a site administrator could, using those DBs manage package de-installation / deactivation or security-alert wrapper scriptage even automatically from it) Note that chromium is in 'main' -- not 'contrib' or ..., so there's a valid expectation that its security support won't just silently stop -- unlike the other FAQ entry that says there's basically no security support or contrib, non-free.. I'm not sure where you get the silently concern from, but this topic is already discussed in wheezy's release notes [1]. The problem with that of course you'll point out is that users often don't read that... By silently, i mean that the package would continue to operate w/o warning that it's possibly vulnerable (sans any external info such as checking DSAs or having an updated 'debian-security-support' package and independently running it to identify the problem). I've often injected shell-script wrappers around problematic packages to warn users via dialog/kdialog/simple-message that the package is vulnerable/problematical, etc -- until the problem's rectified. Yeah, it's hard to read (and brain-store) multiple hundred page manuals for all the stuff a sysadmin is responsible for on a regular basis. That's why i appealed to folks like you to set me straight ;) Best wishes, Mike [0] https://packages.qa.debian.org/d/debian-security-support.html [1] https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#browser-security Thanks! --stephen -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Security EOL within Debian Stable
(after contemplating a possible 'chromium' thread hijack, i figured
this should be a new thread)...
I see a definite problem with the way that package security support
gets end-of-lifed in Debian-Stable.
Not just chromium and other browsers, but the JDK/JRE packages,
historically, as well. I'm not trying to point fingers or criticize,
i legitimately want to know if there's something i'm missing, or if
something could be done to handle package deprecation for security EOL
conditions.
So, if a user installs said package, but fails to notice any EOL DSA
on it, the package gets left in place in a potentially VULNERABLE
state. I.E. if a known exploit comes out, and the package is still
installed, the end-user could get a nasty surprise thinking that
because they've added security support to apt-sources and regularly
update, that they are protected. This is a non-optimal and undesired
end-result.
Now, i'm sure some will argue about Personal Responsibility (keeping
track of all the DSAs, etc), but leaving packages vulnerable in the
Stable release seems to fly in the face of:
https://www.debian.org/security/faq#handling
Q: How is security handled in Debian?
A: Once the security team receives a notification of an incident,
one or more members review it and consider its impact on the stable
release of Debian (i.e. if it's vulnerable or not). If our system is
vulnerable, we work on a fix for the problem. The package maintainer
is contacted as well, if they didn't contact the security team
already. Finally, the fix is tested and new packages are prepared,
which are then compiled on all stable architectures and uploaded
afterwards. After all of that is done, an advisory is published.
Note that chromium is in 'main' -- not 'contrib' or ..., so there's a
valid expectation that its security support won't just silently stop
-- unlike the other FAQ entry that says there's basically no security
support or contrib, non-free..
Is there some mechanism that currently exists that could be used to
flag such security EOL packages?
this could be done by putting out a FINAL EOL security channel
package update that did something like:
- minimally change the package metadata Description to
SECURITY EOL ...
- made the package transition and made it depend on the newly
named package ${package-name}-security-eol
- add a version suffix like ${package} version: ${version}-security-eol
(e.g. chromium 37.0.2062.120-1~deb7u1-security-eol )
- create a new repo component called 'security-eol' to
complement main,contrib.non-free...
...???
It would be quite rude to automatically remove installed packages that
were known vulnerable, obviously, but, maybe that would solve the
problem, and anyone who wanted to willingly keep a package installed
that was EOL/vulnerable, could apt-pin it. Similarly, a security-eol
update could simply remove the executable bits from vulnerable
applications, requiring end-user manual intervention. Still a
shocker, but IMHO a better solution than leaving users vulnerable.
Any comments, ideas, pointers to the reference that answers my
question or points out my confusion... are welcome.
thanks,
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CA+CZZDY8xJcBYmjzFMYRF=lh6uj2s50zov46_cvpkixh+ej...@mail.gmail.com
Re: are unattended updates a good idea?
-- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Re: Efficient way to keep track of security updates
On Wed, Jan 28, 2015 at 1:59 AM, Paul Wise p...@debian.org wrote:
On Wed, Jan 28, 2015 at 4:06 PM, Tiberiu Popescu wrote:
...
You could install and configure the unattended-upgrades package
instead of using apticron. Please note that you still need to do
reboots after Linux kernel updates and relevant restart processes
after library upgrades. You can use needrestart (jessie and later) or
checkrestart (from debian-goodies) to find out which processes to
restart.
ISTM, this libc6 update should have triggered a
/var/run/reboot-required creation, but it didn't. (yeah, it's
debatable, but for the average person, you probably want them to
recognize a reboot is safest after a significant 'libc' security
update -- else more savvy users can figure out to restart critical
daemons if needed)
Here's a script, 'apt-whatsup', i use for showing me what patches are
outstanding (packages that are upgradeable and current and upgradeable
versions). It operates similarly to 'aptitude's 'versions' argument,
but in a more concise layout. It allows selection of security-only
updates via a '-s' option.
AFAICT, a *security* update is only a security update because of where
it comes from (sources.list) by convention/decree.
It's just the same as any other package (the package metadata does not
contain anything identifying the package as a security update).
So, my script may need some adjustment for your environment if your
Debian-Security 'deb' source doesn't look like mine. Or, if you're
using 'squeeze-lts', which is presumed to be 'security only' updates
(Release file 'Label' field won't have Security in it), or if you
have 3rd party security repos, or a multi-release (e.g.
stable+testing)... In that case, you should probably re-architect to
have an /etc/apt/source.list.d/security-updates.list that contains
all your security repos which my script will use directly (if it
exists), rather than trying to ascertain which sources are security
sources and creating a temp sources.list.
If anyone has more insight, let me know.
# Get help
# ./apt-whatsup -h
apt-whatsup:
apt-whatsup [ -d ] [ -n ] [ -s ] [ -k | {search-pattern} ]
This program reports all the outstanding Debian Package Updates
for this system.
-d debug
-k display kernel only updates pending
-n don't do 'aptitude update' phase
-s display security updates only
{search-pattern} any apt-regex search pattern
e.g. cups, ^apache2$
# See what packages and versions (current/upgradeable) are in play for
upgradeable packages
# ./apt-whatsup
Warning, no aptitude update performed, results may be inaccurate...
apache2-mpm-worker 2.2.22-13+deb7u3
2.2.22-13+deb7u4
apache2-utils 2.2.22-13+deb7u3
2.2.22-13+deb7u4
apache2.2-bin 2.2.22-13+deb7u3
2.2.22-13+deb7u4
apache2.2-common2.2.22-13+deb7u3
2.2.22-13+deb7u4
...
# How many upgradable packages are outstanding (use '-n' to avoid
aptitude update, since
# we already did that implicitly in the previous invocation)
# ./apt-whatsup -n | wc -l
Warning, no aptitude update performed, results may be inaccurate...
79
# How many upgradable packages are from security repos
# ./apt-whatsup -s -n | wc -l
Warning, no aptitude update performed, results may be inaccurate...
67
# see if we have a glibc/libc6 security update available
# ./apt-whatsup -s -n '(glibc|libc6)'
Warning, no aptitude update performed, results may be inaccurate...
glibc-doc 2.13-38+deb7u6
2.13-38+deb7u7
libc6 2.13-38+deb7u6
2.13-38+deb7u7
libc6:i386 2.13-38+deb7u6
2.13-38+deb7u7
libc6-dev 2.13-38+deb7u6
2.13-38+deb7u7
libc6-i386 2.13-38+deb7u6
2.13-38+deb7u7
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
apt-whatsup.sh
Description: Bourne shell script
Q: Best Practices for 3rd party APT sources for security considerations?
SUMMARY:
Q: Can a registered 3rd party repo spoof critical packages (e.g.
libc6) and have them installed on apt 'upgrade' operations?
Q: What are the best ways (configuration) to help manage 3rd party
repos to constrain their capabilities?
I have a growing number of users who want all sorts of 3rd party stuff
installed on their desktops (a few hundred), including things like
google chrome|earth, dropbox, etc. Keeping packages updated implies
adding sources.list entries, but...
Is it possible for a 3rd party repository/source added in
/etc/apt/sources.list.d/ to compromise a system by spoofing a new
(higher) version of a critical package, such as 'libc6'?
(aptitude update aptitude upgrade = here, let me install
that new 'libc6' from 'packages-r-us.biz')?
What within apt prevents a spoofage of this nature? (it's unclear to
me that there's any builtin protection against this)
Ultimately, this question is kind of moot, as the mere act of trusting
a 3rd party source for a package installation (or dpkg -i {file})
makes us all sitting ducks, opening your system up to ANY root
activity being performed via a '{pre,post}inst' scripted action or
malware contents -- including having an arbitrary package flat-out
replace libc.so.So a whole lotta faith is being put into that 3rd
party being benevolent, being security conscious in protection of
signing keys, and not ever getting hacked. (is this big elephant in
the room part of why there seems to be a dearth of any detailed Apt
configuration security best practices?) (debsums after the fact
might be a good thing to have configured just to warn when something
does get borked, but in the case of dynamic lib SOs -- nothing stops a
symlink diversion to an alternate .so either, which wouldn't get
reported, since the symlink is dynamically created outside the package
contents)
But, my real question is about how best to configure Apt for when you
*do* make the leap of faith to add a 3rd party source.
There's some question of whether not adding the PGP keys of the
source/package signers and having to manually intervene in the Apt
install warnings is a good idea to keep from accidentally
automatically installing something suspicious. (breaks
unattended-upgrades, obviously) Anybody do this?
Does it make sense to configure APT Preferences to allow only
DESIRED/KNOWN packages from that source to be installable.
I do that for Redhat/Yum via something like:
# Only let CFEngine be installed from EPEL
kwriteconfig --file /etc/yum.repos.d/epel.repo --group 'epel'
--key 'includepkgs' 'cfengine'
E.G. for Google packages, something like:
[/etc/apt/sources.list.d/google*.list]
deb http://dl.google.com/linux/chrome/deb/ stable main
deb http://dl.google.com/linux/earth/deb/ stable main
[/etc/apt/preferences.d/google.pref]
Package: google-earth-stable
Explanation: Allow google-earth-stable to be installed/upgraded
Pin: origin dl.google.com
Pin-Priority: 100
Package: google-chrome-stable
Explanation: Allow google-chrome-stable to be installed/upgraded
Pin: origin dl.google.com
Pin-Priority: 100
Package: *
Explanation: Disallow all other packages from dl.google.com
Pin: origin dl.google.com
Pin-Priority: -1000
lists# apt-cache policy google-chrome-stable
google-chrome-stable:
Installed: 39.0.2171.99-1
Candidate: 40.0.2214.91-1
Package pin: 40.0.2214.91-1
Version table:
40.0.2214.91-1 100
-1000 http://dl.google.com/linux/chrome/deb/ stable/main
amd64 Packages
*** 39.0.2171.99-1 100
100 /var/lib/dpkg/status
AFAICT, this preferences setting *should* disallow 'dl.google.com'
from ever being able to offer a spoofed system package such as
'libc6', allowing that source to only provide the packages
'google-earth-stable' and 'google-chrome-stable'. It would also
prevent the possibility of that source offering a new package that
might accidentally get installed by 'typo' ( new package 'lib6c', hyuk
) or by an administrator who mistakenly sees a package show up
(aptitude search...) that looks useful, thinking it's part of the OS
distribution.
But, is this worthwhile -- does it actually protect you from something
that Apt wouldn't allow anyway?
lists# apt-cache policy libc6 | sed -e 's=\(https\{0,1\}\|ftp\):[^
]*=URI-REDACTED='
libc6:
Installed: 2.13-38+deb7u6
Candidate: 2.13-38+deb7u6
Version table:
*** 2.13-38+deb7u6 0
990 URI-REDACTED wheezy/main amd64 Packages
100 /var/lib/dpkg/status
2.13-38+deb7u4 0
990 URI-REDACTED wheezy/updates/main amd64 Packages
So, i don't have a 3rd party repo defined for libc6 (just site caching
repos). But what is to stop 'dl.google.com' from offering 2.15 of
libc6 and 'aptitude upgrade' installing it?
thanks,
--stephen
--
Stephen Dowdy - Systems Administrator
Re: FW: lists.debian.org has received bounces from you
Tim, Since our organization's infrastructure moved from internally managed to Google Apps for Government (GAG) i have started receiving those occasionally. (sigh) (GAG will abort delivery BEFORE you can even tell it you've whitelisted the sender, which definitely sucks) I personally think they are a GOOD thing -- as NONE of the messages GAG has aborted delivery on was spam in any way, and i'd have never known i was missing them. Having the temporary cache managed by this mailing list software available for you to view is a nice touch -- so count me a fan. --stephen On Tue, Nov 25, 2014 at 4:52 PM, Tim Burke t...@steadfast.net wrote: Anyone else receive this message? The aforementioned bounce message was a phishing message that our spamfilter caught. No big deal of course, just seemingly unnecessary email noise. :-) Tim Burke Systems Administrator Steadfast - Managed Infrastructure and Cloud Services Office: 312.602.2689 x237 | https://steadfast.net -Original Message- From: Debian Listmaster Team [mailto:listmas...@lists.debian.org] Sent: Tuesday, November 25, 2014 17:45 To: t...@steadfast.net Subject: lists.debian.org has received bounces from you Dear subscriber, We've encountered some problems while sending listmail to your emailaddress t...@steadfast.net. ... -- Stephen Dowdy - Systems Administrator - NCAR/RAL 303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
Re: [SECURITY] [DSA 2267-1] perl security update
Wolfgang Jeltsch wrote, On 08/23/2011 09:43 AM:
is there any way to find out which Debian packages use Perl’s Safe
module? What damage could a local attacker have caused by exploiting the
Safe modules’s security flaw?
Wolfgang,
# Debian Package File Search
$ dpfs() { lynx -dump -nolist -width=999
http://packages.debian.org/search?searchon=contentskeywords=${1}mode=filenamesuite=stablearch=any;
| sed -ne '/File[[:space:]]*Packages/,/ _/{x;p}' ;}
$ dpfs Safe.pm
File Packages
/usr/lib/interchange/Vend/Safe.pminterchange
/usr/share/perl/5.10.1/Safe.pm perl-modules
/usr/share/perl5/DBIx/Safe.pmlibdbix-safe-perl
/usr/share/perl5/MIME/Base64/URLSafe.pm
libmime-base64-urlsafe-perl
/usr/share/perl5/Mail/SpamAssassin/Locker/UnixNFSSafe.pm spamassassin
/usr/share/perl5/Test/Trap/Builder/SystemSafe.pm libtest-trap-perl
/usr/share/perl5/Text/MicroMason/Safe.pm
libtext-micromason-perl
Safe.pm appears to be delivered (in squeeze at least) in 'perl-modules'
(unless i'm looking at the wrong thing)
Do a dependency search on anything you have installed that uses that:
$ aptitude search '~i~DDepends:perl-modules'
leave out the '~i' if you don't want to limit to just what you currently
have installed.
Of course that only tells you packages that have metadata indicating that
they depend on 'perl-modules', there could be other things that use it
without notification. (then you're into running global finds looking
for 'use' and 'require' statements, whee!)
--stephen
--
Stephen Dowdy - Systems Administrator - NCAR/RAL
303.497.2869 - sdo...@ucar.edu- http://www.ral.ucar.edu/~sdowdy/
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e53ea65.4090...@ucar.edu
