headers
Ihar Hrachyshka | 6 Apr 2011 01:18
Picon
Gravatar

GSoC 2011 project proposal [Implement file system flags to scrub data blocks before deletion]

Hello everybody!

I am a 1st year Master program student of GIS Centre, Lund University,
Sweden. I'm a Bachelor of Computer Science of Minsk State Higher
Radio-engineering College, Belarus.

Here is my proposal for "Implement file system flags to scrub data
blocks before deletion" GSoC project. Any comments are welcome.

I didn't contact any designated mentors but I hope they will react to
this project proposal here. In a day, I'll send it (with comments
applied) to Google because deadline is already near.

Sorry for sending this proposal that late: I swear there were some
objective reasons for this. :)

What is the goal of the project?
--------------------------------

The goal of the project is to add security feature to vfs layer which
will add ability to scrub blocks which are about to be freed on file
operations like unlink and truncate with 'random' data. This will add
appropriate option (-o scrub?) to mount utility.

Random data will be generated with available hardware generators (f.e.
Intel RNG) or, as a fallback, pseudo-random values' generation
algorithms should be used. We should also consider providing appropriate
sysctl interface to explicitly choose between available algorithms.

This feature will make delete/truncate operations really unrecoverable
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christos Zoulas | 6 Apr 2011 02:39

Re: GSoC 2011 project proposal [Implement file system flags to scrub data blocks before deletion]

In article <4D9BA33D.9010703 <at> gmail.com>,
Ihar Hrachyshka  <ihar.hrachyshka <at> gmail.com> wrote:

>What is the goal of the project?
>--------------------------------
>
>The goal of the project is to add security feature to vfs layer which
>will add ability to scrub blocks which are about to be freed on file
>operations like unlink and truncate with 'random' data. This will add
>appropriate option (-o scrub?) to mount utility.
>
>Random data will be generated with available hardware generators (f.e.
>Intel RNG) or, as a fallback, pseudo-random values' generation
>algorithms should be used. We should also consider providing appropriate
>sysctl interface to explicitly choose between available algorithms.
>
>This feature will make delete/truncate operations really unrecoverable
>which can be considered as additional security merit.

I think we really need to think a bit more about this. I don't think
tht modern disks require random data writes or many rewrites to eliminate
the original data. Just zeroing out the blocks should do it. I also
think that to be effective, this should work at the block allocation
level of the filesystem. I.e. if a filesystem decides to move blocks
around to make things contiguous, or something like a log based filesystem
will leave original file data behind when the file is not removed, and
when the file gets removed the old blocks will still contain pieces of
the file. Finally I don't think that this needs to be controlled in a
finer grain than the mount point.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thor Lancelot Simon | 6 Apr 2011 03:06
Picon
Favicon

Re: GSoC 2011 project proposal [Implement file system flags to scrub data blocks before deletion]

On Wed, Apr 06, 2011 at 12:39:09AM +0000, Christos Zoulas wrote:
> 
> I think we really need to think a bit more about this. I don't think
> tht modern disks require random data writes or many rewrites to eliminate
> the original data. Just zeroing out the blocks should do it. I also

There's certainly little point doing more than rm -P does.  Nor is there
any real advantage -- and there are some real disadvantages -- to using
random data from a hardware generator rather than a PRNG.

I think this project would end up touching many or most -- if not all --
the exact same code paths that TRIM support for SSDs would touch; and
I note there's a real issue with TRIM 'hiding' sectors without causing
them to read-back as all 0 when reallocated, on at least a few devices, so
when we do implement TRIM support, we may want some form of prezeroing
first.

Consequently, I think this project should be more generic -- that there
should be a set of flags, set by the filesystem when it schedules the
I/O, that cause the lower layers to do various things to the blocks in
question: zero them, do the 0xff-0x00-random dance, TRIM them, or
perhaps each in succession.

I agree the mount point is the right granularity for control of this.

Thor
Permalink | Reply | 0 comments |
headers
Sarah W. | 6 Apr 2011 11:26

Any interest? Building Industry Marketing List 273,027 Records w/ Emails (Updated 2011)

Hello,

I sent this message to you some time ago but received no
response. Did it reach you? Please let me know should you be
interested.

I have compiled a list of 273,027 US builders, contractors,
architects, interior designers, developers and related
professionals. This is a great market for various
products/services.

The list is the result of several years' hard work, last
update - February 2011.

All the records have: company name, full address, phone, fax,
email address, contact name, trade. Website addresses also
available but not for all of them.

The list can be produced in any common format, such as Excel,
CSV data file etc. Just let me know which one you would prefer.
This can be used it for direct mailing, email campaigns, cold
calling etc.

The list includes practically everyone ranging from professional
designers to decision makers of large corporations.

If you want to proceed and expand your business, I could share
the list with you for a fee of $400. For your information I can
send you a sample in Excel (say 100 contacts).
(Continue reading)

Permalink | Reply | 0 comments |
headers
NetBSD Security Officer | 7 Apr 2011 15:58
Picon

NetBSD Security Advisory 2011-004: Kernel stack overflow via nested IPCOMP packet


		 NetBSD Security Advisory 2011-004
		 =================================

Topic:		Kernel stack overflow via nested IPCOMP packet

Version:	NetBSD-current:		source prior to April 1st, 2011
		NetBSD 5.0.*:		affected
		NetBSD 5.0:		affected
		NetBSD 5.1:		affected
		NetBSD 4.0.*:		affected
		NetBSD 4.0:		affected

Severity:	remote DOS, possible memory corruption

Fixed:		NetBSD-current:		April 1st, 2011
		NetBSD-5-0 branch:	April 3rd, 2011
			(5.0.3 will include the fix)
		NetBSD-5-1 branch:	April 3rd, 2011
			(5.1.1 will include the fix)
		NetBSD-5 branch:	April 3rd, 2011
		NetBSD-4-0 branch:	April 3rd, 2011
		NetBSD-4 branch:	April 3rd, 2011

Please note that NetBSD releases prior to 4.0 are no longer supported.
It is recommended that all users upgrade to a supported release.

Abstract
========
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frère Sébastien Marie | 20 Apr 2011 11:13
Picon
Favicon

about vulnerabilities without advisories: how to keep informed

Hi,

I have noted that severals vulnerabilities are corrected in NetBSD release branchs but without any advisories.

http://www.netbsd.org/support/security/ mention advisories for "serious security problems", but
how keep informed about others security problems ?

Here a list from NetBSD-5-0 branch (taken from src/doc/CHANGES-5.0.3), in order to flag the problem.

Please notie that all of these are currently without advisories, so are not "serious security problems"
(or perhaps advisory process is engaged... but all are more 12 day old)

* CVE-2011-0997 [spz, ticket #1595], Thu Apr 7 17:25:47 2011 UTC
  dhclient in ISC DHCP 3.0.x through 4.2.x before 4.2.1-P1, 3.1-ESV before 3.1-ESV-R1, and 4.1-ESV before
4.1-ESV-R2 allows remote attackers to execute arbitrary commands via shell metacharacters in a
hostname obtained from a DHCP message.
  CVSS v2 Base Score:7.5 (HIGH) [from nvd.nist.gov]  

* CVE-2011-0465 [mrg, ticket #1594], Thu Apr 7 06:56:25 2011 UTC
  xrdb.c in xrdb before 1.0.9 in X.Org X11R7.6 and earlier allows remote attackers to execute arbitrary
commands via shell metacharacters in a hostname obtained from a (1) DHCP or (2) XDMCP message
  CVSS v2 Base Score:9.3 (HIGH) [from nvd.nist.gov]

* unassigned-CVE [christos, ticket #1593], Tue Apr 5 06:23:12 2011 UTC
  "Protect against stack smashes."
  so should be have security consideration, according to the description, and to the fact changes are
pull-up in release branch

* unassigned-CVE [spz, ticket #1586], Tue Mar 29 20:13:51 2011 UTC
  "Clean up setting ECN bit in TOS.  Fixes PR 44742"
(Continue reading)

Permalink | Reply | 1 comment |
headers
S.P.Zeidler | 23 Apr 2011 18:13
Picon

Re: about vulnerabilities without advisories: how to keep informed

Hi,

semarie-netbsd <at> latrappe.fr (Frère Sébastien Marie) writes:

>I have noted that severals vulnerabilities are corrected in NetBSD release branchs but without any advisories.

>http://www.netbsd.org/support/security/ mention advisories for "serious security problems", but
how keep informed about others security problems ?

Since noone else is picking this up ..

Issues where root would need to run a problematic binary usually fall
below the 'needs an advisory' threshold, as do problems that need a rather
unusual configuration to bite. Another threshold is vulnerabilities
in HEAD only: these get fixed, but no advisory.

>Here a list from NetBSD-5-0 branch (taken from src/doc/CHANGES-5.0.3), in order to flag the problem.

>Please notie that all of these are currently without advisories, so are not "serious security problems"
(or perhaps advisory process is engaged... but all are more 12 day old)

>* CVE-2011-0997 [spz, ticket #1595], Thu Apr 7 17:25:47 2011 UTC
>  dhclient in ISC DHCP 3.0.x through 4.2.x before 4.2.1-P1, 3.1-ESV before 3.1-ESV-R1, and 4.1-ESV before
4.1-ESV-R2 allows remote attackers to execute arbitrary commands via shell metacharacters in a
hostname obtained from a DHCP message.
>  CVSS v2 Base Score:7.5 (HIGH) [from nvd.nist.gov]  

This should get an advisory yet.

>* CVE-2011-0465 [mrg, ticket #1594], Thu Apr 7 06:56:25 2011 UTC
(Continue reading)

Permalink | Reply | 0 comments |
headers
NetBSD Security Officer | 26 Apr 2011 21:37
Picon

NetBSD Security Advisory 2011-005: ISC dhclient hostname field shell metacharacter injection


		 NetBSD Security Advisory 2011-005
		 =================================

Topic:		ISC dhclient does not strip shell meta-characters in
		environment variables passed to scripts.

Version:	NetBSD-current:		affected
		NetBSD 5.1:		affected
		NetBSD 5.0:		affected
		NetBSD 4.0.*:		affected
		NetBSD 4.0:		affected
		pkgsrc:			isc-dhclient4 package prior to
					4.2.1-P1

Severity:	Arbitrary Script Execution

Fixed:		NetBSD-current:		April 6th, 2011
		NetBSD-5-0 branch:	April 7th, 2011
		NetBSD-5 branch:	April 7th, 2011
		NetBSD-4-0 branch:	April 7th, 2011
		NetBSD-4 branch:	April 7th, 2011
		pkgsrc 2011Q1:		April 11th, 2011

Abstract
========

dhclient doesn't strip or escape certain shell meta-characters in
dhcpd responses, allowing a rogue server or party with with escalated
privileges on the server to cause remote code execution on the client.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeremy C. Reed | 26 Apr 2011 22:00

Re: NetBSD Security Advisory 2011-005: ISC dhclient hostname field shell metacharacter injection

On Tue, 26 Apr 2011, NetBSD Security Officer wrote:

> $old_ip_address are IP addresses), one should either patch dhclient
> to sanitize all variables or add the following line to
> /sbin/dhclient-script at the beginning of the set_hostname()
> function:

I wish I reviewed the advisory first (for ISC and for NetBSD). That 
set_hostname is not part of ISC's nor NetBSD's script.

So maybe put workaround near top of script.

> new_host_name="$(echo "${new_host_name}" | sed -e 's/[^a-zA-Z0-9-]*//g')"

At least the BASHism wasn't copied to this advisory :)
Permalink | Reply | 0 comments |
headers
Jeremy C. Reed | 26 Apr 2011 22:07

Re: NetBSD Security Advisory 2011-005: ISC dhclient hostname field shell metacharacter injection

On Tue, 26 Apr 2011, NetBSD Security Officer wrote:

> new_host_name="$(echo "${new_host_name}" | sed -e 's/[^a-zA-Z0-9-]*//g')"
> 
> The reason to do this, is that unless the hostname is sanitized,
> a hostname with shell metacharacters can be set on the system, and
> other scripts might break that use the compromised hostname.

Unrelated to DHCP, should we consider making it so the hostname(1) tool, 
sethostname(3), and/or sysctl kern.hostname do not accept junk?

I was quite surprised what I could set as my hostname when I looked at 
this a couple week ago.

When is it okay for hostname to contain strange characters? (Any odd but 
real working examples to share?)
Permalink | Reply | 8 comments |

Gmane