Re: getusershell: off by one
On Thu, Jan 16, 2014 at 08:23:52PM +0100, Tobias Stoeckmann wrote:
> Hi,
>
> the library function getusershell(3) assumes that the smallest possible
> line in /etc/shells would be 3 chars (slash, a char, new line):
> In that case, there are at max sb.st_size / 3 of lines. Well, that is not
> entirely correct. The last line could be just 2 chars, skipping the
> trailing new line. The integer division rounds down, therefore an off by
> one is possible.
>
> If you are able to just get past the allocated page into the next guard
> page, users of getusershell(3) crash:
>
> $ uname -m
> i386
> $ head -n2 /etc/shells # and so on
> /a
> /a
> $ ls -l /etc/shells
> -rw-r--r-- 1 root wheel 49152 Jan 15 22:40 /etc/shells
> $ chpass
> Segmentation fault
>
> Okay?
>
ok gilles@
> Index: getusershell.c
> ===
> RCS file: /var/www/cvs/src/lib/libc/gen/getusershell.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 getusershell.c
> --- getusershell.c24 Nov 2013 23:51:29 - 1.11
> +++ getusershell.c16 Jan 2014 19:14:43 -
> @@ -109,7 +109,7 @@ initshells(void)
> (void)fclose(fp);
> return (okshells);
> }
> - shells = calloc((size_t)(statb.st_size / 3), sizeof (char *));
> + shells = calloc((size_t)(statb.st_size / 3 + 1), sizeof (char *));
> if (shells == NULL) {
> (void)fclose(fp);
> free(strings);
>
--
Gilles Chehade
https://www.poolp.org @poolpOrg
ntfs hash memory
Are you using NTFS? Probably not. So why have you reserved 16K for the
NTFS hash table?
We can postpone nthashinit() until mount and save memory for people
who aren't using ntfs. Also, the other init function, toupper_init,
doesn't do anything at all.
Index: ntfs_ihash.c
===
RCS file: /cvs/src/sys/ntfs/ntfs_ihash.c,v
retrieving revision 1.13
diff -u -p -r1.13 ntfs_ihash.c
--- ntfs_ihash.c30 May 2013 20:11:06 - 1.13
+++ ntfs_ihash.c17 Jan 2014 05:07:34 -
@@ -60,8 +60,19 @@ struct rwlock ntfs_hashlock = RWLOCK_INI
void
ntfs_nthashinit(void)
{
- ntfs_nthashtbl = hashinit(desiredvnodes, M_NTFSNTHASH, M_WAITOK,
- &ntfs_nthash);
+ u_long nthash;
+ void *nthashtbl;
+
+ if (ntfs_nthashtbl)
+ return;
+
+ nthashtbl = hashinit(desiredvnodes, M_NTFSNTHASH, M_WAITOK, &nthash);
+ if (ntfs_nthashtbl) {
+ free(nthashtbl, M_NTFSNTHASH);
+ return;
+ }
+ ntfs_nthashtbl = nthashtbl;
+ ntfs_nthash = nthash;
}
/*
Index: ntfs_subr.c
===
RCS file: /cvs/src/sys/ntfs/ntfs_subr.c,v
retrieving revision 1.36
diff -u -p -r1.36 ntfs_subr.c
--- ntfs_subr.c 2 Dec 2013 16:23:16 - 1.36
+++ ntfs_subr.c 17 Jan 2014 05:02:08 -
@@ -1877,17 +1877,6 @@ ntfs_runtocn(cn_t *cn, struct ntfsmount
#endif
/*
- * this initializes toupper table & dependant variables to be ready for
- * later work
- */
-void
-ntfs_toupper_init(void)
-{
- ntfs_toupper_tab = (wchar *) NULL;
- ntfs_toupper_usecount = 0;
-}
-
-/*
* if the ntfs_toupper_tab[] is filled already, just raise use count;
* otherwise read the data from the filesystem we are currently mounting
*/
Index: ntfs_subr.h
===
RCS file: /cvs/src/sys/ntfs/ntfs_subr.h,v
retrieving revision 1.8
diff -u -p -r1.8 ntfs_subr.h
--- ntfs_subr.h 2 Dec 2013 16:19:08 - 1.8
+++ ntfs_subr.h 17 Jan 2014 05:07:58 -
@@ -93,7 +93,6 @@ void ntfs_ntrele(struct ntnode *);
int ntfs_loadntnode( struct ntfsmount *, struct ntnode * );
int ntfs_writentvattr_plain(struct ntfsmount *, struct ntnode *, struct
ntvattr *, off_t, size_t, void *, size_t *, struct uio *);
int ntfs_writeattr_plain(struct ntfsmount *, struct ntnode *, u_int32_t, char
*, off_t, size_t, void *, size_t *, struct uio *);
-void ntfs_toupper_init(void);
int ntfs_fget(struct ntfsmount *, struct ntnode *, int, char *, struct fnode
**);
void ntfs_frele(struct fnode *);
int ntfs_ntreaddir(struct ntfsmount *, struct fnode *, u_int32_t, struct
attr_indexentry **, struct proc *);
Index: ntfs_vfsops.c
===
RCS file: /cvs/src/sys/ntfs/ntfs_vfsops.c,v
retrieving revision 1.37
diff -u -p -r1.37 ntfs_vfsops.c
--- ntfs_vfsops.c 2 Dec 2013 16:05:07 - 1.37
+++ ntfs_vfsops.c 17 Jan 2014 05:02:24 -
@@ -113,8 +113,6 @@ ntfs_sysctl(int *name, u_int namelen, vo
int
ntfs_init(struct vfsconf *vcp)
{
- ntfs_nthashinit();
- ntfs_toupper_init();
return 0;
}
@@ -128,6 +126,8 @@ ntfs_mount(struct mount *mp, const char
char fname[MNAMELEN];
char fspec[MNAMELEN];
mode_t amode;
+
+ ntfs_nthashinit();
/*
***
getusershell: off by one
Hi,
the library function getusershell(3) assumes that the smallest possible
line in /etc/shells would be 3 chars (slash, a char, new line):
In that case, there are at max sb.st_size / 3 of lines. Well, that is not
entirely correct. The last line could be just 2 chars, skipping the
trailing new line. The integer division rounds down, therefore an off by
one is possible.
If you are able to just get past the allocated page into the next guard
page, users of getusershell(3) crash:
$ uname -m
i386
$ head -n2 /etc/shells # and so on
/a
/a
$ ls -l /etc/shells
-rw-r--r-- 1 root wheel 49152 Jan 15 22:40 /etc/shells
$ chpass
Segmentation fault
Okay?
Tobias
Index: getusershell.c
===
RCS file: /var/www/cvs/src/lib/libc/gen/getusershell.c,v
retrieving revision 1.11
diff -u -p -r1.11 getusershell.c
--- getusershell.c 24 Nov 2013 23:51:29 - 1.11
+++ getusershell.c 16 Jan 2014 19:14:43 -
@@ -109,7 +109,7 @@ initshells(void)
(void)fclose(fp);
return (okshells);
}
- shells = calloc((size_t)(statb.st_size / 3), sizeof (char *));
+ shells = calloc((size_t)(statb.st_size / 3 + 1), sizeof (char *));
if (shells == NULL) {
(void)fclose(fp);
free(strings);
Fix for CVE-2013-4353 (OpenSSL)
Hello,
the following diff addresses CVE-2013-4353
(OpenSSL - TLS record tampering bug).
Index: src/ssl/s3_both.c
===
RCS file: /cvs/src/lib/libssl/src/ssl/s3_both.c,v
retrieving revision 1.12
diff -u -p -u -p -r1.12 s3_both.c
--- src/ssl/s3_both.c 14 Feb 2013 15:11:43 - 1.12
+++ src/ssl/s3_both.c 16 Jan 2014 16:03:53 -
@@ -207,6 +207,12 @@ int ssl3_send_finished(SSL *s, int a, in
static void ssl3_take_mac(SSL *s) {
const char *sender;
int slen;
+
+ /* If no new cipher setup return immediately: other functions will
+* set the appropriate error.
+*/
+ if (s->s3->tmp.new_cipher == NULL)
+ return;
if (s->state & SSL_ST_CONNECT)
{
Cheers,
Sebastian
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4353
[2]
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=197e0ea817ad64820789d86711d55ff50d71f631
Re: ulpt question
On Wed, Jan 15, 2014 at 11:41:05PM -0800, Philip Guenther wrote: > On Wed, Jan 15, 2014 at 11:07 PM, patrick keshishian > wrote: > > Now here, I need an expert's help. I must be looking at > > this upside down or sideways, because I don't see where > > ulpt_do_write() is called, well, it is called from ulptwrite() > > (ulpt.c), but I can't find who, or where it gets called from. > > Need a pointer here please. > > ulptwrite is referenced via the d_write member for ulpt in the cdevsw > array, and is thus invoked via spec_write() in kern/spec_vnops.c. > > (How does it get into cdevsw? Look for ulpt in sys/conf.h and in > arch/*/*/conf.c; the latter uses the macros defined in the former.) Thanks for the pointer! That was a fun exercise! :-) On Thu, Jan 16, 2014 at 09:02:21AM +, Stuart Henderson wrote: > On 2014/01/15 23:07, patrick keshishian wrote: > > Setting that aside, it doesn't look like I can use ulpt device > > to write a dedicated "driver" for this printer. Is this correct? > > Do I need to "fudge" the kernel to not attach this device to > > ulpt but instead as ugen? Is there a better way? I rather not > > diverge from GENERIC. > > There's some support in libusb for accessing non-ugen(4) devices, > specifically control transfers and synchronous reads. I'll take a look a libusb. > But if this code is to do some necessary initialization for a particular > printer that can be matched by IDs, adding support right in the ulpt(4) > driver would probably be better, there's already some framework for matching > things by ID for printers which need firmware to be uploaded, so you could > possibly hook into this. I did notice the HP firmware load routines, also mentioned by Stefan Sperling. On Thu, Jan 16, 2014 at 10:35:05AM +0100, Stefan Sperling wrote: > > there's already some framework for matching > > things by ID for printers which need firmware to be uploaded, so you could > > possibly hook into this. > > In particular, the ulpt_ucode_loader_hp() function writes a firmware > image as raw bytes to the printer. Re-using code from this function > you should be able to write arbitrary data to the printer. > Fun fact: The implementation of ulpt_ucode_loader_hp() was based > on code from ugen_do_write(), i.e. ulpt behaves like ugen while > it uploads firmware to HP printers. I'll look more closely at those again. Thank you Philip, Stuart and Stefan for quick responses! --patrick
Re: pkg_add (pkg.conf): option to require signed packages
On 2014/01/16 08:53, Sébastien Marie wrote: > Hi, > > Does it make sens to have an option to require package to be signed ? It makes more sense to just enable that by default, when we are happy with the infrastructure and usage.
Re: ulpt question
On Thu, Jan 16, 2014 at 09:02:21AM +, Stuart Henderson wrote: > But if this code is to do some necessary initialization for a particular > printer that can be matched by IDs, adding support right in the ulpt(4) > driver would probably be better, Agreed. > there's already some framework for matching > things by ID for printers which need firmware to be uploaded, so you could > possibly hook into this. In particular, the ulpt_ucode_loader_hp() function writes a firmware image as raw bytes to the printer. Re-using code from this function you should be able to write arbitrary data to the printer. Fun fact: The implementation of ulpt_ucode_loader_hp() was based on code from ugen_do_write(), i.e. ulpt behaves like ugen while it uploads firmware to HP printers.
Re: ulpt question
On 2014/01/15 23:07, patrick keshishian wrote: > Setting that aside, it doesn't look like I can use ulpt device > to write a dedicated "driver" for this printer. Is this correct? > Do I need to "fudge" the kernel to not attach this device to > ulpt but instead as ugen? Is there a better way? I rather not > diverge from GENERIC. There's some support in libusb for accessing non-ugen(4) devices, specifically control transfers and synchronous reads. But if this code is to do some necessary initialization for a particular printer that can be matched by IDs, adding support right in the ulpt(4) driver would probably be better, there's already some framework for matching things by ID for printers which need firmware to be uploaded, so you could possibly hook into this.
