Re: I unveil()ed ftp(1)!
I made symbolic links “ln -s /etc/ssl/cert.pem ”. I used the
realpath command and it worked in the software I submitted.
On Thu, Jun 4, 2020 at 11:06 AM Theo de Raadt wrote:
> No.
>
> I'm guessing you don't understand symbolic links.
>
> Look, this is a waste of time.
>
>
> Luke Small wrote:
>
> > --80daf105a7444c30
> > Content-Type: text/plain; charset="UTF-8"
> > Content-Transfer-Encoding: 8bit
> >
> > In the case of 1 URLs couldn’t you at least merely unveil “./“ as
> “cw”;
> > make any specified cafile/capath including shortcut resolution as “r”
> > (perhaps with the shell “x”) so that at worst, current directory files
> > could be overwritten, but not read?
> >
> > On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt
> wrote:
> >
> > > You really don't get it.
> > >
> > > + unveil_list = calloc(2 * argc, sizeof(char*));
> > >
> > > Imagine argc is 1.
> > >
> > > + for (i = 2 * argc - 2; i >= 0; i -= 2) {
> > > + if (unveil_list[i]) {
> > > + if (unveil(unveil_list[i],
> "r") ==
> > > -1)
> > > ...
> > > + if (unveil_list[i | 1]) {
> > > + if (unveil(unveil_list[i | 1],
> > > "cw") == -1)
> > > + err(1, "unveil");
> > > ...
> > >
> > >
> > > E2BIG The addition of path would exceed the
> per-process
> > > limit for unveiled paths.
> > >
> > >
> > > Great, under fairly normal usage ftp aborts with an error.
> > >
> > > Since you start with up to 8 others, it looks like this limit is easily
> > > hit at around 120 filenames.
> > >
> > > So ftp simply fails to perform the task it is designed for.
> > >
> > > Your proposal is to break the command.
> > >
> > > --
> > -Luke
> >
> > --80daf105a7444c30
> > Content-Type: text/html; charset="UTF-8"
> > Content-Transfer-Encoding: 8bit
> >
> > In the case of 1 URLs couldn’t you at least
> merely unveil “./“ as “cw”; make any specified cafile/capath including
> shortcut resolution as “r” (perhaps with the shell “x”) so that at worst,
> current directory files could be overwritten, but not
> read? class="gmail_attr">On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt href="mailto:dera...@openbsd.org;>dera...@openbsd.org
> wrote:You
> really dont get it.
> >
> > + unveil_list = calloc(2 * argc,
> sizeof(char*));
> >
> > Imagine argc is 1.
> >
> > + for (i = 2 * argc - 2; i = 0; i -= 2) {
> > + if (unveil_list[i]) {
> > + if (unveil(unveil_list[i],
> r) == -1)
> > ...
> > + if (unveil_list[i | 1]) {
> > + if (unveil(unveil_list[i | 1],
> cw) == -1)
> > + err(1,
> unveil);
> > ...
> >
> >
> > E2BIG The addition of path would exceed the
> per-process
> > limit for unveiled paths.
> >
> >
> > Great, under fairly normal usage ftp aborts with an error.
> >
> > Since you start with up to 8 others, it looks like this limit is
> easily
> > hit at around 120 filenames.
> >
> > So ftp simply fails to perform the task it is designed for.
> >
> > Your proposal is to break the command.
> >
> > -- data-smartmail="gmail_signature">-Luke
> >
> > --80daf105a7444c30--
>
--
-Luke
Re: I unveil()ed ftp(1)!
In the case of 1 URLs couldn’t you at least merely unveil “./“ as “cw”;
make any specified cafile/capath including shortcut resolution as “r”
(perhaps with the shell “x”) so that at worst, current directory files
could be overwritten, but not read?
On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt wrote:
> You really don't get it.
>
> + unveil_list = calloc(2 * argc, sizeof(char*));
>
> Imagine argc is 1.
>
> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
> + if (unveil_list[i]) {
> + if (unveil(unveil_list[i], "r") ==
> -1)
> ...
> + if (unveil_list[i | 1]) {
> + if (unveil(unveil_list[i | 1],
> "cw") == -1)
> + err(1, "unveil");
> ...
>
>
> E2BIG The addition of path would exceed the per-process
> limit for unveiled paths.
>
>
> Great, under fairly normal usage ftp aborts with an error.
>
> Since you start with up to 8 others, it looks like this limit is easily
> hit at around 120 filenames.
>
> So ftp simply fails to perform the task it is designed for.
>
> Your proposal is to break the command.
>
> --
-Luke
Re: I unveil()ed ftp(1)!
No.
I'm guessing you don't understand symbolic links.
Look, this is a waste of time.
Luke Small wrote:
> --80daf105a7444c30
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
>
> In the case of 1 URLs couldnât you at least merely unveil â./â as
> âcwâ;
> make any specified cafile/capath including shortcut resolution as ârâ
> (perhaps with the shell âxâ) so that at worst, current directory files
> could be overwritten, but not read?
>
> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt wrote:
>
> > You really don't get it.
> >
> > + unveil_list = calloc(2 * argc, sizeof(char*));
> >
> > Imagine argc is 1.
> >
> > + for (i = 2 * argc - 2; i >= 0; i -= 2) {
> > + if (unveil_list[i]) {
> > + if (unveil(unveil_list[i], "r") ==
> > -1)
> > ...
> > + if (unveil_list[i | 1]) {
> > + if (unveil(unveil_list[i | 1],
> > "cw") == -1)
> > + err(1, "unveil");
> > ...
> >
> >
> > E2BIG The addition of path would exceed the per-process
> > limit for unveiled paths.
> >
> >
> > Great, under fairly normal usage ftp aborts with an error.
> >
> > Since you start with up to 8 others, it looks like this limit is easily
> > hit at around 120 filenames.
> >
> > So ftp simply fails to perform the task it is designed for.
> >
> > Your proposal is to break the command.
> >
> > --
> -Luke
>
> --80daf105a7444c30
> Content-Type: text/html; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
>
> In the case of 1 URLs couldnât you at least merely
> unveil â./â as âcwâ; make any specified cafile/capath including
> shortcut resolution as ârâ (perhaps with the shell âxâ) so that at
> worst, current directory files could be overwritten, but not
> read? class="gmail_attr">On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt href="mailto:dera...@openbsd.org;>dera...@openbsd.org
> wrote:You
> really dont get it.
>
> +Â Â Â Â Â Â Â Â Â Â Â Â unveil_list = calloc(2 * argc,
> sizeof(char*));
>
> Imagine argc is 1.
>
> +Â Â Â Â Â Â Â Â Â Â Â Â for (i = 2 * argc - 2; i = 0; i -= 2)
> {
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (unveil_list[i]) {
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if
> (unveil(unveil_list[i], r) == -1)
> ...
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if (unveil_list[i | 1]) {
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â if
> (unveil(unveil_list[i | 1], cw) == -1)
> +Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â
> err(1, unveil);
> ...
>
>
> Â Â Â E2BIGÂ Â Â Â Â Â Â The addition of path would exceed the
> per-process
> Â Â Â Â Â Â Â Â Â Â Â Â limit for unveiled paths.
>
>
> Great, under fairly normal usage ftp aborts with an error.Â
>
> Since you start with up to 8 others, it looks like this limit is easily
> hit at around 120 filenames.
>
> So ftp simply fails to perform the task it is designed for.
>
> Your proposal is to break the command.
>
> -- data-smartmail="gmail_signature">-Luke
>
> --80daf105a7444c30--
Re: I unveil()ed ftp(1)!
there was tiny error I created.
-Luke
On Wed, Jun 3, 2020 at 2:24 PM Luke Small wrote:
> There! It doesn't use an unveil list. It has 2 dry runs as proposed.
> It could just have a dry run to see if it goes into interactive mode
> and then unveil as we go! but I like to see all the unveil calls before
> the ftp output statements myself!
> -Luke
>
>
> On Wed, Jun 3, 2020 at 11:30 AM Luke Small wrote:
>
>> Or you could have 2 dry runs. One to merely see that it won't head into
>> interactive mode
>> and a second one to start the unveiling directly in fetch.c. Unless
>> unveil itself will
>> have too many entries!
>> -Luke
>>
>>
>> On Wed, Jun 3, 2020 at 11:12 AM Luke Small wrote:
>>
>>> I figure if it took up that much stack space from before, it'd start
>>> needing to
>>> dang near run the stack into on-disk virtual memory anyway. At that
>>> point,
>>> it'd perhaps be a better design choice to break up your ftp calls into
>>> slightly
>>> smaller chunks to avoid massively poor performance, yeah? LOL
>>>
>>> If you're really worried about it, perhaps you could put in a goto which
>>> jumps
>>> over the offending part, when argc is so massive that
>>> it would cause such a thing...Hmmm.
>>> -Luke
>>>
>>>
>>> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt
>>> wrote:
>>>
You really don't get it.
+ unveil_list = calloc(2 * argc, sizeof(char*));
Imagine argc is 1.
+ for (i = 2 * argc - 2; i >= 0; i -= 2) {
+ if (unveil_list[i]) {
+ if (unveil(unveil_list[i], "r")
== -1)
...
+ if (unveil_list[i | 1]) {
+ if (unveil(unveil_list[i | 1],
"cw") == -1)
+ err(1, "unveil");
...
E2BIG The addition of path would exceed the
per-process
limit for unveiled paths.
Great, under fairly normal usage ftp aborts with an error.
Since you start with up to 8 others, it looks like this limit is easily
hit at around 120 filenames.
So ftp simply fails to perform the task it is designed for.
Your proposal is to break the command.
Common subdirectories: /usr/src/usr.bin/ftp/CVS and /home/luke/ftp/CVS
diff -uNp /usr/src/usr.bin/ftp/extern.h /home/luke/ftp/extern.h
--- /usr/src/usr.bin/ftp/extern.h Thu May 16 07:44:17 2019
+++ /home/luke/ftp/extern.h Wed Jun 3 13:41:49 2020
@@ -69,6 +69,7 @@ void abortrecv(int);
void alarmtimer(int);
int another(int *, char ***, const char *);
int auto_fetch(int, char **, char *);
+int auto_fetch_u(int, char **, char *, int, int);
void blkfree(char **);
void cdup(int, char **);
void cmdabort(int);
diff -uNp /usr/src/usr.bin/ftp/fetch.c /home/luke/ftp/fetch.c
--- /usr/src/usr.bin/ftp/fetch.c Fri Feb 21 19:00:07 2020
+++ /home/luke/ftp/fetch.c Wed Jun 3 15:51:45 2020
@@ -68,8 +68,10 @@ struct tls;
#include "ftp_var.h"
#include "cmds.h"
-static int file_get(const char *, const char *);
+//~ static int file_get(const char *, const char *);
+static int file_get_u(const char *, const char *, int, int);
static int url_get(const char *, const char *, const char *, int);
+static int url_get_u(const char *, const char *, const char *, int, int, int);
static int save_chunked(FILE *, struct tls *, int , char *, size_t);
static void aborthttp(int);
static void abortfile(int);
@@ -186,8 +188,14 @@ tooslow(int signo)
* Copy a local file (used by the OpenBSD installer).
* Returns -1 on failure, 0 on success
*/
+//~ static int
+//~ file_get(const char *path, const char *outfile)
+//~ {
+ //~ return file_get_u(path, outfile, 1, 0);
+//~ }
+
static int
-file_get(const char *path, const char *outfile)
+file_get_u(const char *path, const char *outfile, int ready, int tout)
{
struct stat st;
int fd, out, rval = -1, save_errno;
@@ -200,17 +208,28 @@ file_get(const char *path, const char *outfile)
direction = "received";
- fd = open(path, O_RDONLY);
- if (fd == -1) {
- warn("Can't open file %s", path);
- return -1;
- }
+ if (ready) {
+
+ fd = open(path, O_RDONLY);
+ if (fd == -1) {
+ warn("Can't open file %s", path);
+ return -1;
+ }
- if (fstat(fd, ) == -1)
- filesize = -1;
- else
- filesize = st.st_size;
+ if (fstat(fd, ) == -1)
+ filesize = -1;
+ else
+ filesize = st.st_size;
+ } else {
+ if (unveil(path, "r") == -1)
+ err(1, "unveil");
+ dprintf(tout, "unveil(%s, \"r\")\n", path);
+ if (pipeout)
+ return 0;
+ }
+
+
if (outfile != NULL)
savefile = outfile;
else {
@@ -220,6 +239,14 @@ file_get(const char *path, const char *outfile)
savefile = basename(path);
}
+ if (!ready) {
+ if (unveil(savefile, "cw") == -1)
+ err(1, "unveil");
+
+ dprintf(tout, "unveil(%s, \"cw\")\n", savefile);
+ return 0;
+ }
+
if
Re: I unveil()ed ftp(1)!
There! It doesn't use an unveil list. It has 2 dry runs as proposed.
It could just have a dry run to see if it goes into interactive mode
and then unveil as we go! but I like to see all the unveil calls before
the ftp output statements myself!
-Luke
On Wed, Jun 3, 2020 at 11:30 AM Luke Small wrote:
> Or you could have 2 dry runs. One to merely see that it won't head into
> interactive mode
> and a second one to start the unveiling directly in fetch.c. Unless unveil
> itself will
> have too many entries!
> -Luke
>
>
> On Wed, Jun 3, 2020 at 11:12 AM Luke Small wrote:
>
>> I figure if it took up that much stack space from before, it'd start
>> needing to
>> dang near run the stack into on-disk virtual memory anyway. At that point,
>> it'd perhaps be a better design choice to break up your ftp calls into
>> slightly
>> smaller chunks to avoid massively poor performance, yeah? LOL
>>
>> If you're really worried about it, perhaps you could put in a goto which
>> jumps
>> over the offending part, when argc is so massive that
>> it would cause such a thing...Hmmm.
>> -Luke
>>
>>
>> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt
>> wrote:
>>
>>> You really don't get it.
>>>
>>> + unveil_list = calloc(2 * argc, sizeof(char*));
>>>
>>> Imagine argc is 1.
>>>
>>> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
>>> + if (unveil_list[i]) {
>>> + if (unveil(unveil_list[i], "r")
>>> == -1)
>>> ...
>>> + if (unveil_list[i | 1]) {
>>> + if (unveil(unveil_list[i | 1],
>>> "cw") == -1)
>>> + err(1, "unveil");
>>> ...
>>>
>>>
>>> E2BIG The addition of path would exceed the per-process
>>> limit for unveiled paths.
>>>
>>>
>>> Great, under fairly normal usage ftp aborts with an error.
>>>
>>> Since you start with up to 8 others, it looks like this limit is easily
>>> hit at around 120 filenames.
>>>
>>> So ftp simply fails to perform the task it is designed for.
>>>
>>> Your proposal is to break the command.
>>>
>>>
/* $OpenBSD: fetch.c,v 1.194 2020/02/22 01:00:07 jca Exp $ */
/* $NetBSD: fetch.c,v 1.14 1997/08/18 10:20:20 lukem Exp $ */
/*-
* Copyright (c) 1997 The NetBSD Foundation, Inc.
* All rights reserved.
*
* This code is derived from software contributed to The NetBSD Foundation
* by Jason Thorpe and Luke Mewburn.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS
* ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
* TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
/*
* FTP User Program -- Command line file retrieval
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef NOSSL
#include
#else /* !NOSSL */
struct tls;
#endif /* !NOSSL */
#include "ftp_var.h"
#include "cmds.h"
//~ static int file_get(const char *, const char *);
static int file_get_u(const char *, const char *, int, int);
static int url_get(const char *, const char *, const char *, int);
static int url_get_u(const char *, const char *, const char *, int, int, int);
static int save_chunked(FILE *, struct tls *, int , char *, size_t);
static void aborthttp(int);
static void abortfile(int);
static char hextochar(const char *);
static char *urldecode(const char *);
static char *recode_credentials(const char *_userinfo);
static char *ftp_readline(FILE *, size_t *);
static void ftp_close(FILE **, struct tls **, int *);
static const char *sockerror(struct tls *);
#ifdef SMALL
#define ftp_printf(fp, ...) fprintf(fp, __VA_ARGS__)
#else
static int ftp_printf(FILE *, const char *,
Re: I unveil()ed ftp(1)!
Or you could have 2 dry runs. One to merely see that it won't head into
interactive mode
and a second one to start the unveiling directly in fetch.c. Unless unveil
itself will
have too many entries!
-Luke
On Wed, Jun 3, 2020 at 11:12 AM Luke Small wrote:
> I figure if it took up that much stack space from before, it'd start
> needing to
> dang near run the stack into on-disk virtual memory anyway. At that point,
> it'd perhaps be a better design choice to break up your ftp calls into
> slightly
> smaller chunks to avoid massively poor performance, yeah? LOL
>
> If you're really worried about it, perhaps you could put in a goto which
> jumps
> over the offending part, when argc is so massive that
> it would cause such a thing...Hmmm.
> -Luke
>
>
> On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt wrote:
>
>> You really don't get it.
>>
>> + unveil_list = calloc(2 * argc, sizeof(char*));
>>
>> Imagine argc is 1.
>>
>> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
>> + if (unveil_list[i]) {
>> + if (unveil(unveil_list[i], "r")
>> == -1)
>> ...
>> + if (unveil_list[i | 1]) {
>> + if (unveil(unveil_list[i | 1],
>> "cw") == -1)
>> + err(1, "unveil");
>> ...
>>
>>
>> E2BIG The addition of path would exceed the per-process
>> limit for unveiled paths.
>>
>>
>> Great, under fairly normal usage ftp aborts with an error.
>>
>> Since you start with up to 8 others, it looks like this limit is easily
>> hit at around 120 filenames.
>>
>> So ftp simply fails to perform the task it is designed for.
>>
>> Your proposal is to break the command.
>>
>>
Re: I unveil()ed ftp(1)!
I figure if it took up that much stack space from before, it'd start
needing to
dang near run the stack into on-disk virtual memory anyway. At that point,
it'd perhaps be a better design choice to break up your ftp calls into
slightly
smaller chunks to avoid massively poor performance, yeah? LOL
If you're really worried about it, perhaps you could put in a goto which
jumps
over the offending part, when argc is so massive that
it would cause such a thing...Hmmm.
-Luke
On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt wrote:
> You really don't get it.
>
> + unveil_list = calloc(2 * argc, sizeof(char*));
>
> Imagine argc is 1.
>
> + for (i = 2 * argc - 2; i >= 0; i -= 2) {
> + if (unveil_list[i]) {
> + if (unveil(unveil_list[i], "r") ==
> -1)
> ...
> + if (unveil_list[i | 1]) {
> + if (unveil(unveil_list[i | 1],
> "cw") == -1)
> + err(1, "unveil");
> ...
>
>
> E2BIG The addition of path would exceed the per-process
> limit for unveiled paths.
>
>
> Great, under fairly normal usage ftp aborts with an error.
>
> Since you start with up to 8 others, it looks like this limit is easily
> hit at around 120 filenames.
>
> So ftp simply fails to perform the task it is designed for.
>
> Your proposal is to break the command.
>
>
Re: I unveil()ed ftp(1)!
You really don't get it.
+ unveil_list = calloc(2 * argc, sizeof(char*));
Imagine argc is 1.
+ for (i = 2 * argc - 2; i >= 0; i -= 2) {
+ if (unveil_list[i]) {
+ if (unveil(unveil_list[i], "r") == -1)
...
+ if (unveil_list[i | 1]) {
+ if (unveil(unveil_list[i | 1], "cw") ==
-1)
+ err(1, "unveil");
...
E2BIG The addition of path would exceed the per-process
limit for unveiled paths.
Great, under fairly normal usage ftp aborts with an error.
Since you start with up to 8 others, it looks like this limit is easily
hit at around 120 filenames.
So ftp simply fails to perform the task it is designed for.
Your proposal is to break the command.
Re: I unveil()ed ftp(1)!
I’ll be the first to admit that I don’t completely understand the power that is the ftp client. but what I do understand of it, from the perspective of noninteractive commandline execution, it seems to fit the bill. For file and http(s) transfers. I didn’t see any buffer overflows and I’m sure that my solution would’ve thrown some segfaults if it had overrun a buffer in my testing. All the comments like how I needed to resolve soft links of cafile have been dealt with, but I’m not shy about putting in single letter variables to perform nested looping. But it seems that the task that said couldn’t be done, was done. It adds complexity that I’m sure you aren’t comfortable with; especially since your name is on the file as the last author, but you can’t say I’m not that demandy lazy ass that didn’t do anything about it now. On Wed, Jun 3, 2020 at 9:50 AM Theo de Raadt wrote: > I mean it is amusing, because this is never going to fly. > > This increase in complexity is completely unacceptable, what I see is > completely amateurish, and I also see overflows, a lack of testing > for edge conditions, and a lack of attention to how unveil works. > > > Luke Small wrote: > > > You're welcome! I figured you might not want a “massive” diff to cap off > your day to > > make a program that you apparently feel is secure enough, but I made > good that I got > > off my ass and did something anyway. I’m surprised that you even went to > the trouble of > > pledging it myself. It only took 2 or 3 days to figure out what it was > doing and change > > it. I left in the fprintf()s to so that I could amuse you. > > > > I’m kinda surprised that you didn’t go straight for the “submit a diff. > Anything you > > submit will just be rejected anyway!” > > > > On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt > wrote: > > > > Thank you for the laugh. > > > > Luke Small wrote: > > > > > I think I'm done tinkering. try these out in ftp folder. I left in > some > > > fprintf(ttyout,...) in main.c > > > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > > > and SSL_PATH variables. > > > It leaves in place the functionality of the original functions, but > adds > > > the availability to perform > > > a dry run pass to load an unveil list of potential files from which > to read > > > and create/write. > > > The only potential bug is perhaps if in the followup unveiled pass if > it > > > has a problem with dns resolution or > > > something, it may be unveiled and drop into a command line. I'm not > sure. > > > > > > The diff is of the three files below vs the originals since I last > updated > > > the source files. > > > > > > -Luke > > > -- > > > -Luke > > > > -- > > -Luke > > > -- -Luke
Re: I unveil()ed ftp(1)!
I mean it is amusing, because this is never going to fly. This increase in complexity is completely unacceptable, what I see is completely amateurish, and I also see overflows, a lack of testing for edge conditions, and a lack of attention to how unveil works. Luke Small wrote: > You're welcome! I figured you might not want a “massive” diff to cap off your > day to > make a program that you apparently feel is secure enough, but I made good > that I got > off my ass and did something anyway. I’m surprised that you even went to the > trouble of > pledging it myself. It only took 2 or 3 days to figure out what it was doing > and change > it. I left in the fprintf()s to so that I could amuse you. > > I’m kinda surprised that you didn’t go straight for the “submit a diff. > Anything you > submit will just be rejected anyway!” > > On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt wrote: > > Thank you for the laugh. > > Luke Small wrote: > > > I think I'm done tinkering. try these out in ftp folder. I left in some > > fprintf(ttyout,...) in main.c > > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > > and SSL_PATH variables. > > It leaves in place the functionality of the original functions, but adds > > the availability to perform > > a dry run pass to load an unveil list of potential files from which to read > > and create/write. > > The only potential bug is perhaps if in the followup unveiled pass if it > > has a problem with dns resolution or > > something, it may be unveiled and drop into a command line. I'm not sure. > > > > The diff is of the three files below vs the originals since I last updated > > the source files. > > > > -Luke > > -- > > -Luke > > -- > -Luke >
Re: I unveil()ed ftp(1)!
You're welcome! I figured you might not want a “massive” diff to cap off your day to make a program that you apparently feel is secure enough, but I made good that I got off my ass and did something anyway. I’m surprised that you even went to the trouble of pledging it myself. It only took 2 or 3 days to figure out what it was doing and change it. I left in the fprintf()s to so that I could amuse you. I’m kinda surprised that you didn’t go straight for the “submit a diff. Anything you submit will just be rejected anyway!” On Wed, Jun 3, 2020 at 9:39 AM Theo de Raadt wrote: > Thank you for the laugh. > > > Luke Small wrote: > > > I think I'm done tinkering. try these out in ftp folder. I left in some > > fprintf(ttyout,...) in main.c > > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > > and SSL_PATH variables. > > It leaves in place the functionality of the original functions, but adds > > the availability to perform > > a dry run pass to load an unveil list of potential files from which to > read > > and create/write. > > The only potential bug is perhaps if in the followup unveiled pass if it > > has a problem with dns resolution or > > something, it may be unveiled and drop into a command line. I'm not sure. > > > > The diff is of the three files below vs the originals since I last > updated > > the source files. > > > > -Luke > > -- > > -Luke > -- -Luke
Re: I unveil()ed ftp(1)!
Thank you for the laugh. Luke Small wrote: > I think I'm done tinkering. try these out in ftp folder. I left in some > fprintf(ttyout,...) in main.c > to show what is being unveiled. It resolves shortcuts in SSL_CAFILE > and SSL_PATH variables. > It leaves in place the functionality of the original functions, but adds > the availability to perform > a dry run pass to load an unveil list of potential files from which to read > and create/write. > The only potential bug is perhaps if in the followup unveiled pass if it > has a problem with dns resolution or > something, it may be unveiled and drop into a command line. I'm not sure. > > The diff is of the three files below vs the originals since I last updated > the source files. > > -Luke > -- > -Luke
I unveil()ed ftp(1)!
I think I'm done tinkering. try these out in ftp folder. I left in some
fprintf(ttyout,...) in main.c
to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
and SSL_PATH variables.
It leaves in place the functionality of the original functions, but adds
the availability to perform
a dry run pass to load an unveil list of potential files from which to read
and create/write.
The only potential bug is perhaps if in the followup unveiled pass if it
has a problem with dns resolution or
something, it may be unveiled and drop into a command line. I'm not sure.
The diff is of the three files below vs the originals since I last updated
the source files.
-Luke
--
-Luke
diff
Description: Binary data
/* $OpenBSD: main.c,v 1.131 2020/02/11 18:41:39 deraadt Exp $ */
/* $NetBSD: main.c,v 1.24 1997/08/18 10:20:26 lukem Exp $ */
/*
* Copyright (C) 1997 and 1998 WIDE Project.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. Neither the name of the project nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* Copyright (c) 1985, 1989, 1993, 1994
* The Regents of the University of California. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* 3. Neither the name of the University nor the names of its contributors
*may be used to endorse or promote products derived from this software
*without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* FTP User Program -- Command Interface.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include "cmds.h"
#include "ftp_var.h"
#ifndef SMALL
#include "pathnames.h"
#endif
int connect_timeout;
#ifndef NOSSL
char * const ssl_verify_opts[] = {
#define SSL_CAFILE 0
"cafile",
#define SSL_CAPATH 1
"capath",
#define SSL_CIPHERS 2
"ciphers",
#define SSL_DONTVERIFY 3
"dont",
#define SSL_DOVERIFY 4
"do",
#define SSL_VERIFYDEPTH 5
"depth",
#define SSL_MUSTSTAPLE 6
"muststaple",
#define SSL_NOVERIFYTIME 7
"noverifytime",
#define SSL_SESSION 8
"session",
NULL
};
struct tls_config *tls_config;
int tls_session_fd = -1;
static void
process_ssl_options(char *cp, char *ca_file, char *ca_path)
{
const char *errstr;
long long depth;
char *str;
while (*cp) {
switch (getsubopt(, ssl_verify_opts, )) {
case SSL_CAFILE:
if (str == NULL)
errx(1, "missing CA file");
